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ABSTRACT 



Upper-level managers at Silas B. Hays Army Community Hospital (SBHACH), Fort 
Ord, CA, are tasked with the administrative operation of a Medical Treatment Facility pro- 
viding various health-care services to the surrounding military community. This broad 
mission requires hospital administrators to analyze large amounts of data when commonly 
tasked with solving ill- structured problems resulting from managing such a large hospital. 
The thesis research presents the use of a Decision Support System (DSS) to support upper- 
level managers faced with ill-structured problems and discusses the use of structured inter- 
views in deriving the resource manager’s critical information needs. These Critical Success 
Factors (CSFs) are presented in detail and proposed measures that a DSS should possess to 
satisfy these critical information needs are identified. The design of the first iteration of the 
Resource Management DSS using structured software design tools provides the necessary 
documentation from which the system may be implemented. 
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I. INTRODUCTION 



A. BACKGROUND 

1. General Mission of U. S. Army Health-Care Services 

Like any precious resource in the Department of Defense (DOD), medical 
health-care services are regarded as finite and subject to budgetary limitations. Within the 
U. S. Army, commanding officers of Medical Treatment Facilities (MTFs) are assigned the 
responsibility for administration of patients under their jurisdiction. The MTF commanding 
officer is specifically tasked with providing the best possible health care for each patient, 
ensuring such care is consistent with professional health-care procedures and standards 
[Army Reg 40-3 85]. 

This broad mission, coupled with fluctuating expertise levels of health-care 
providers and scarce resources, compounds an already difficult task of managing a MTF. 
The Silas B. Hays Army Community Hospital (SBHACH), Fort Ord, California, is no 
exception. The commanding officer and his staff are tasked with managing the daily oper- 
ation of the MTF by providing professional medical health-care services to different levels 
of DOD personnel, all without exceeding annual budget funding. Compliance with this 
goal is difficult, requiring the analysis of large amounts of information. 

2. Need for Information Management 

Resource managers at SBHACH draw data from several in-place Management 
Information Systems (MIS) to support decision making. Unfortunately in most cases, 
extracted data from an existing MIS is not readily useable. Often the data must be com- 
bined with other MIS outputs and put into a recognizable format for management use. For 
example, to find the average cost the hospital incurs per outpatient visit over a period of 
time requires data from one MIS providing total outpatients treated, and data from a second 
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MIS providing total cost spent on outpatients. This data is then combined into a useful 
ratio for SBHACH resource managers. However, extracting and correlating data into use- 
ful information often administratively overburdens managers. Personnel tasked with 
extraction and correlation tasks sometimes duplicate effort, repeat the same procedures 
done for earlier periods, and may provide varying results even though they use the same 
data. There is a need for a system that provides a systematic, structured approach to satisfy 
management information needs. 

A Decision Support System (DSS) specifically developed for SBHACH resource 
managers will provide this structured approach by supplying on request timely and consis- 
tent information, which is extracted and correlated without undue administrative burden. 

B . INTRODUCTION TO DECISION SUPPORT SYSTEMS (DSS) 

A DSS is a computer-based, interactive system that aids decision makers in con- 
fronting ill- structured problems through the use of data and analysis [Sprague 82]. The 
role of a DSS is to provide necessary information in a useable format, on time, to the deci- 
sion maker who needs it. In this context, a properly designed DSS for SBHACH will 
support decision makers by satisfying information needs. The DSS on demand will tie into 
existing MIS, extract necessary data, combine this data with other outputs into a meaning- 
ful form, and present the information to decision makers in a timely manner. 

A theoretical framework for DSS is developed in Chapter II. In this chapter, the 
reader will be familiarized with the general characteristics of a DSS, planning and building 
a DSS, management role in developing a DSS, and other DSS concepts important to the 
research. Where appropriate, specific applications from the theoretical understanding of a 
DSS to the actual case at SBHACH are made. The purpose of moving between theory and 
practical application is to demonstrate the direction of research followed in analyzing and 
designing the DSS for SBHACH. 
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C. METHODOLOGY AND OBJECTIVES OF RESEARCH 



In order to properly conduct the analysis and design of a DSS for SBHACH, a 
structured approach was used to elicit management information needs, analyze current 
information systems, and design the proposed DSS. Critical Success Factor (CSF) inter- 
views were conducted to identify information needs, existing MIS were studied for use by 
the delivered product, and a structured design methodology was implemented in designing 
the proposed DSS. 

1. Research Questions 

The following research questions were developed in order to fulfill the goal of 
this thesis as a document from which a useful DSS may be implemented: 

• How should one best determine Critical Success Factors for a large hospital, specifi- 
cally Silas B. Hays Army Community Hospital (SBHACH), Fort Ord, California? 

• What are the Critical Success Factors for SBHACH? 

• What should a Decision Support System look like in order to support decision makers 
in meeting these Critical Success Factors? 

• What must be done to build such a Decision Support System? 

By thoroughly researching these questions and presenting the answers in a 
concise form, the goals of this thesis will be satisfied. 

2. Critical Success Factors (CSFs) 

Chief executives are finding more and more that they are inundated with data in 
an unusable form. Managers examine reports, determine what pieces of information are 
important, and take the necessary action [Rockart 79]. The same is true for upper-level 
management at SBHACH [Appendix A]. The information required to make timely deci- 
sions is present in existing MIS, but not in useable form to make decisions based solely on 
a single MIS output. The most difficult part of analyzing management information needs is 
eliciting what “key areas” of business activity are necessary to obtain good results for a 
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manager to reach established goals [Rockart 82]. These “key areas” are called Critical 
Success Factors (CSFs) and are a major concern for decision makers in order to perform 
well, regardless of the industry in which they operate. 

Critical Success Factors are used to generally describe what managers need to 
be concerned with in their daily business functions. A more precise definition of CSFs is 
found in Bullen and Rockart’s article “A Primer on Critical Success Factors,” defining 
CSFs as: 

The limited number of areas in which satisfactory results will ensure successful com- 
petitive performance for the individual, department, or organization. CSFs are those 
key areas where “things must go right” for the business to flourish and for the man- 
ager’s goals to be attained [Bullen 81]. 

Managers may not be able to explicitly state exactly what their CSFs are, but 
they know or have a feeling for the information they require in order to satisfy these CSFs. 
Most managers have implicit CSFs that they have been using without consciously knowing 
it to help them manage. By using a structured interview technique, implicit CSFs are made 
explicit [Bullen 81]. 

The author conducted a series of structured interviews of upper-level manage- 
ment at SBHACH using Appendix B as a guide. Synopses of interviews are contained in 
Appendix C, and from these interviews CSF information needs were determined for devel- 
opment into a DSS. Chapter III provides a detailed analysis of CSF development. 

3. Existing Hospital MIS 

A DSS will draw upon existing MIS that have already been developed in order 
to support identified information needs. After information requirements are presented, a 
synopsis of in-place MIS is discussed to identify where data may be obtained to satisfy 
user needs. 

SBHACH has in place approximately five different stand-alone MIS. During 
the course of research it was necessary to study the existing MIS to determine what 
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information is collected and the form it is in. This research was done through interviews of 
information systems personnel at SBHACH (summarized in Appendix D) and MIS docu- 
mentation studies. Chapter III also provides a detailed analysis of this portion of the 
research. 

4. Structured Analysis and Structured Design Methodology 

Structured Analysis and Structured Design use a systematic approach to develop 
a software product that is maintainable, reliable, and adaptable [Page-Jones 80]. By using 
the tools of this methodology, this thesis produces a properly documented software product 
from which a working DSS may easily be implemented. 

Once CSF data were obtained, outputs from Structured Analysis and Structured 
Design methodologies were developed and presented in Chapter IV. The deliverables from 
this method — Data Flow Diagrams (DFDs), Data Dictionaries (DDs), structure charts, 
mini-specifications, and module specifications — are presented in the appendices as docu- 
mentation for the DSS. These outputs will allow information systems personnel to easily 
implement the designed DSS. 

The different stand-alone MIS at SBHACH run on different and sometimes 
incompatible hardware. The programs are written in different programming languages and 
supported by civilian contract personnel. Integration of software modules developed by 
SBHACH personnel into the different stand-alone systems to extract data was ruled out due 
to possible violation of existing commercial contracts. Chapter IV describes the approach 
taken to remove needed data from the different MIS to support the designed DSS. 

D. ASSUMPTIONS AND LIMITATIONS OF RESEARCH 

The scope of the thesis was limited in size to accommodate an adequate amount of 
proposed measures to satisfy CSFs and still provide a useful product. The proposed mea- 
sures incorporated into the DSS were limited to a manageable number for a single thesis 
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student to adequately develop. Adding to the size of the DSS by follow-on research is dis- 
cussed in the final chapter. 

Implementation was not considered an overall goal. A thorough analysis of design 
effort first must be completed. Further, SBHACH information systems personnel are 
better qualified to choose the programming language with which they wish to implement 
the developed DSS. If they code the DSS, they will more easily maintain the final product 
for future use due to familiarity developed during the implementation phase. 

E. BENEFITS OF RESEARCH 

The delivered product will provide documentation from which a DSS may be imple- 
mented. Once the DSS is implemented, it will provide a significant increase in relevant 
information flow to managers who need it. This system will quickly extract needed data 
and manipulate it into a useable form for presentation to decision makers. This aspect of 
the system itself will eliminate the inordinate amount of time expended on hand extraction 
of data and consolidation of numerous disjointed reports. 

Follow-on research is suggested in the area of aiding information systems personnel 
in implementing the delivered product. A large amount of coding and testing will be 
required before the DSS is implemented. Another area of research to be explored is the 
continuation of CSF interviews and adding to the breadth of the DSS by satisfying more 
information needs. 

F. ORGANIZATION OF THESIS 

In this chapter, a brief introduction to the background of the thesis and the methodol- 
ogy and objectives of the research were presented. The reader was introduced to the CSF 
interview technique to elicit information needs from management personnel at SBHACH 
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and the proposed implementation of the delivered product by information systems 
personnel. 

Chapter II establishes a theoretical framework from which the DSS is developed. 
Chapter II familiarizes the reader with the characteristics and purpose of a DSS, manage- 
ment’s role in developing and justifying a DSS, planning and building a DSS, and DSS 
architecture theory. 

Chapters III and IV present the detailed analysis and design of the SBHACH DSS. 
Chapter III describes the interviews used to analyze information needs of upper-level man- 
agement. The CSFs are prioritized in this chapter and existing MIS details and computer 
resources are presented in detail. Chapter IV provides the transformation of the analysis 
conducted to the software design of the actual DSS. The outputs of the Structured Analysis 
and Structured Design method are formally presented from the appendices resulting in the 
documentation of the DSS. Finally, Chapter V summarizes the research conducted and 
provides suggestions for the implementation phase of the delivered product. 
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II. DEVELOPING A THEORETICAL FOUNDATION OF DECISION 
SUPPORT AND DECISION SUPPORT SYSTEMS 



In recent years, there have been significant developments in the Decision Support 
Systems (DSS) field. A review of pertinent literature provides various definitions of what 
DSS are and how decision support can aid decision makers. In this chapter, a relevant 
framework is developed from publications by respected DSS researchers. Where appro- 
priate in the framework presentation, a bridge between theory and the proposed DSS at 
Silas B. Hays Army Community Hospital (SBHACH) will be made. 

Most of the publications read offered varied characteristics of decision support and 
DSS. The next section presents characteristics of DSS deemed most relevant. 

A. DSS CHARACTERISTICS 

Decision support is looked upon as an approach to analyzing complex organizational 
decision making and the ways decision making can be aided through computer technology. 
In this section, general definitions and DSS purpose are presented, the level of management 
supported by a DSS is discussed, and the relationship of Management Information System 
(MIS) technology to decision support is identified. This provides the reader with a better 
understanding of the philosophy behind decision support and the ways it can aid organiza- 
tional decision making. 

1. DSS Definition and Purpose 

Any discussion about DSS should start with the differences in terminology 
between a DSS and a “decision support system.” Huber explains that each individual has a 
personal decision support system, a “dss,” which is used daily in organizational decision 
making. This system uses various methods to collect and categorize relevant data and uses 
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decision aids to examine possible outcomes of alternatives analyzed. In essence, managers 
use a variety of resources to ask “What if?” questions to decide on a particular problem 
solution. A Decision Support System (DSS) is that part of the personal decision support 
system, a “dss,” that is automated or computer enhanced [Huber 81]. A difference in 
terminology is made here. A “dss” does not have to be automated by computer technology, 
but a DSS takes advantage of the processing and modeling power of computer technology. 

Keen summarizes that an important goal of a DSS is for decision makers to 
learn more about the decision problem and a DSS is suited to provide this learning envi- 
ronment [Keen 87]. From this summary, a DSS can be described as a computer-enhanced 
management learning tool that aids decision makers in defining the decision problem and 
analyzing possible alternatives. 

A broad definition of a DSS is provided by Sprague and Carlson in their book 
[Sprague 82]. They define DSS as having the following characteristics: 

• Computer based systems; 

• That help decision makers; 

• Confront ill-structured problems; 

• Through direct interaction; 

• With data and analysis. 

This general definition provides a useful “checklist” with which a DSS for 
SBHACH may be evaluated in later chapters. 

Ford presents a DSS as incorporating features from management information 
systems, management science, and operations research technologies into a system that 
draws upon all technologies for a synergistic effect [Ford 85]. This synergistic whole of 
man and computer is much greater than the sum of the parts — man and computer perform- 
ing decision making separately. An interactive computer-based system accessing data 
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databases and allowing decision makers to perform “What if?” analysis will achieve desired 
synergy. 

A 1981 study of eight commercial DSS by Keen showed that different DSS 
applications have many common characteristics but all should have four features to be suc- 
cessful [Keen 81]. As a minimum, a DSS should be the following: 

• Flexible to handle different situations; 

• Easy to use; 

• Responsive; 

• Communicative. 

These four factors were important to consider when developing a DSS for 
SBHACH because ignoring any one of these factors might cause the product to lapse into 
disuse. The delivered product when implemented should address several identified critical 
problems. The DSS should be easy to use for novices as well as experienced computer 
users; to encourage use, the DSS should also feature a user dialog responsive to user 
queries. 

This section explicitly points out that DSS are developed to aid managers in 
their decision making tasks. The question arises then whether DSS should be available for 
all managers within an organization, or whether DSS should be built for a specific organi- 
zational management level. The next section addresses this question about which managers 
within an organization a DSS should support. 

2. Level of Management Supported By a DSS 

Ackoff explains that a DSS tends to be used for semi-structured and ill-struc- 
tured problems. He points out that these less-structured problems are commonly faced by 
upper-level managers [Ackoff 67]. Lower-level managers deal with more structured prob- 
lems that have known solutions and thereby make a DSS difficult to cost justify. 
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Alexander echoes the level of management supported by pointing out that a DSS should 
provide relevant, boiled-down data to senior managers or, simply, high-level information 
for high-level people [Alexander 86]. Sprague states that upper- level managers usually 
deal with less structured problems and a DSS can provide needed information for decision 
making [Sprague 86]. 

The proposed DSS is intended for use by senior resource managers at 
SBHACH. The DSS will provide these upper-level mangers with relevant information to 
address the ill- structured problems they face. Chapter El provides more detail in identify- 
ing which managers the DSS will support at SBHACH. 

3. MIS Versus DSS 

A review of the literature brought out some important concepts about the rela- 
tionship between MIS and DSS technologies. It is important to present an MIS and DSS 
overview to discuss their interaction with one another, and specifically how MIS can sup- 
port DSS, differences in the types of management problems supported by each technology, 
and the separation of decision making and information gathering. These distinctions will 
be key in defining how the MIS at SBHACH will be used in conjunction with the designed 
DSS. 

a. MIS Support of DSS 

Due to the many existing stand-alone MIS at SBHACH, it is necessary to 
discuss how an MIS is used in relation to a DSS. Alexander proposes that an MIS sup- 
ports a DSS in that: 

A DSS does not replace or compete with other systems; instead, it extracts from other 
systems the information that is essential to the process of decision making. 
[Alexander 86] 

Figure 2-1 graphically depicts a DSS acting as an intermediary between 
user and data sources. The DSS accesses the different MIS, manipulates the data, and 



11 



selectively presents the processed information to users. Chapter III provides a specific 
description of how existing MIS at SBHACH will support the developed DSS. 




Figure 2-1. Management Information Systems (MIS) in Relation to Decision 

Support Systems (DSS) 

As discussed earlier, DSS are used to support upper-level managers con- 
fronted by ill- structured problems. This next section differentiates the varied levels of 
problem structure facing different levels of managers and which technology, MIS or DSS, 
is best suited for implementation in the different cases. 

b. MIS and DSS Problem Structure 

MIS and DSS are developed to support different types of management 
problems within an organization. The different types of problems to be discussed range 
from structured to unstructured problem areas. Figure 2-2 shows the different levels of 
problem structures within an organization; inside each cell are types of sample management 
problems faced by decision makers. These problem types are not always clear cut and tend 
to be less defined categories [Gorry 71]. According to Gorry and Scott Morton, a nebu- 
lous dividing line at the semi-structured decision level can be drawn separating the figure 
into two areas: structured or unstructured problems. These two areas are not well defined 
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on the fringes of the separation but represent levels of problem structure tending to be sup- 
ported by either MIS or DSS applications. 
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Figure 2-2. Different Levels of Decision Making Supported by Management 
Information System (MIS) or Decision Support System (DSS) Technologies 



A management problem is considered structured if it is repetitive, routine, 
and most of the decision making process may be automated. An unstructured problem is a 
novel, new problem that has not been faced by managers before [Simon 60]. Structured 
and unstructured problems differ in their requirements for information and computer 
support. 

The upper half of Figure 2-2 deals with structured problems and informa- 
tion needs for structured problems. Because these problem types have little to do with real 
information management, they are best satisfied by MIS or data-processing technologies. 
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The area below the separation contains more complex variables. These unstructured prob- 
lem areas are best addressed using DSS capabilities [Gorry 71]. 

In essence, MIS are used to support lower-level managers who deal with 
more routine or structured decision-making tasks. On the other hand, DSS aid upper-level 
managers when faced with non-routine or unstructured decision making tasks. 

c. Information Gathering and Decision Making Separation 

The previous sections discussed the different purposes of MIS and DSS 
technologies in relation to the level of management supported and the structure of problems 
addressed. This section provides a differentiation between MIS and DSS in relation to 
gathering information and decision making. 

It is important to define at what point in the decision process an MIS 
leaves off and a DSS picks up. The decision process is a combination of the information 
system and the decision-making system. The information system is the process through 
which data is collected and stored. The decision-making system is the actual person or 
persons responsible with analyzing the information, analyzing alternatives based on data 
presented, and choosing an alternative. The entire decision process deals with collecting 
data from various sources, making predictions and drawing inferences from the data, 
assigning values from inferences drawn, and taking action. Figure 2-3(a) depicts the 
sequence of events from data collection to action taking that combine the information and 
decision-making systems into the decision process [Mason 81]. 

Figure 2-3(b) represents support an MIS lends to the decision process. 
The information system is tasked with storing, retrieving, and classifying potentially useful 
data for the decision-making system. The decision-making system then determines from 
which areas the data must be retrieved and makes these requests to the information system. 
Mason points out that it is not feasible for the information system to have the capability of 
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retrieving all combinations and permutations of possible requests. Therefore, the decision 
system is tasked with generating these requests, drawing inferences and predictions from 
delivered reports, assigning values, and choosing a course of action. Figure 2-3 (b) repre- 
sents the MIS level of support present at SBHACH. 
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(c) DSS Support of Decision Process 
Figure 2-3. MIS and DSS Support of Decision Process 

The designed DSS for SBHACH will go a step beyond the MIS level and 
provide predictive information to decision makers. Figure 2-3(c) combines the ability to 
make predictions and draw inferences from the data. In this manner, the decision-making 
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system can ask “What if?” questions and get appropriate, timely responses from the infor- 
mation system. The decision-making system then assigns values to possible choices and 
takes action. As will be seen in Chapter III, Figure 2-3(c) represents the separation of the 
information and decision-making systems for the SBHACH DSS. 

B . PLANNING AND BUILDING A DSS 

So far, definitions of a DSS and how one can support an organization’s decision- 
making process have been provided along with the differences between MIS and DSS 
technologies. This section will now present different development methods that are used 
for planning and building DSS. 

Historically, the methodology used by systems analysts to develop computer software 
has been the systems development life cycle (SDLC) process. As a system is conceived 
and moves from idea conception to implementation, it must pass through several steps. 
Davis describes a typical SDLC in Figure 2-4 [Davis 83]. 
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Figure 2-4. Classic Systems Development Life Cycle Waterfall Model 
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When this structured approach is used, an analyst must start with problem definition 
and methodically progress from one step to the next. As specific requirements for each 
step are completed, the development moves to the next step, with overlap occurring 
between steps [Davis 83]. For the most part, specific requirements must be met during 
each step before system evolution can progress to the next step. This approach of system- 
atically moving through the life cycle, although a disciplined practice for systems develop- 
ment, is not appropriate to the development of a DSS. 

A typical system can be developed using the steps in Figure 2-4 because at the begin- 
ning of the life cycle, the problem can be isolated by a skilled systems analyst and defined 
to a degree necessary to begin the remaining steps. Unlike this approach, a DSS cannot be 
well defined at the beginning. Analysts and designers have difficulty in eliciting manage- 
ment information needs because decision makers cannot define in advance what the system 
should do. Planning and building a DSS is not just purchasing hardware and developing 
software to support decision makers. It is planning, designing, and studying the organiza- 
tion’s decision making processes [Alexander 86]. There are different methods of studying 
this decision making process and constructing a DSS, of which two will be presented here. 

1. DSS Building Methods 

The two DSS building methods presented, though not always distinct, are dis- 
cussed to develop a flavor for the complex approach of constructing a DSS. The two 
approaches are the iterative and the adaptive methods. The major similarities and the minor 
differences of the iterative and adaptive methods are presented to introduce an alternative 
building method to the SDLC methodology. 
a. Iterative Method 

The iterative approach to DSS development combines the first several 
steps in Figure 2-4. It is a building block approach that the DSS builder uses to meet actual 
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user requirements. A sub-problem is agreed upon between user and developer, a system is 
designed to satisfy this sub-problem, and the system is presented to the user for feedback. 
The builder makes necessary corrections and continues the process by building onto the 
existing system. This loop is repeated several times. As the product is added to and 
revised, the user is involved with the builder continuously to provide constant feedback 
[Sprague 80]. Figure 2-5 demonstrates the iterative process between the builder and user. 



ITERATION OF DSS 
FOR USER REVIEW 




USER CRITIQUE AND 
SUGGESTED CHANGES 

Figure 2-5. User/Builder Relationship of Iterative Development Method 



The product is never really finished, but the frequency of loops decreases 
until a useable product finally stabilizes for use. This approach is different from prototyp- 
ing in that the first deliverable is a useable system and not a test case. The deliverable may 
not perform all functions the user requires, but it can be iteratively built upon to encompass 
a great deal of user requirements. The iterative method incorporates the first steps of the 
SDLC method shown in Figure 2-4 into a large feedback cycle. The concentration is on the 
link established between the user and the builder. The adaptive method, on the other hand, 
focuses on three links. 

b. Adaptive Method 

The adaptive method is very similar to the iterative method in that it also 
combines several steps of the systems development life cycle method. The adaptive 
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approach uses feedback from the user to build upon and change the product to user specifi- 
cations as demonstrated in Figure 2-5, but also incorporates two other links. This adaptive 
approach focuses on three elements involved in building a DSS as shown in Figure 2-6 and 
concentrates on the three links between these elements in developing the product [Alavi 
84]. 




Figure 2-6. Adaptive Elements of DSS Development 

The user-system link deals with studying the effects a user’s characteris- 
tics will have on operating the DSS. This area includes user cognitive styles addressed 
later in this chapter, experience and background of computer use, and user problem-solving 
techniques. This link is important to make and establishes who will be using the DSS and 
what their attitudes are towards computing. This link takes into account the dialog existing 
between user and DSS and the effect it has on the user. 

The system-builder link involves the flexibility of system architecture. It 
allows the addition of features and changes to existing ones to accommodate added 
capabilities. These changes should be made without undue time and resource expenditures. 
As a builder understands more of the user’s needs and the user understands more of what a 
DSS can do, incorporating this new knowledge quickly and efficiently into the DSS will 
further enhance the delivered product. 
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Finally, the user-builder link is the communication link necessary to 
develop the DSS. This collaboration allows the user to learn about the power decision 
support can give to the decision maker and allows the builder to leam about user require- 
ments and build credibility [Alavi 84]. 

Similar to the iterative method, the builder and user agree upon a sub- 
problem of user requirements to be incorporated into the DSS. The builder constructs a 
rough product of the DSS to satisfy this sub-problem and presents the product to the user 
for review. The difference between the adaptive and iterative methods is the builder’s 
focus on the relationships between builder, user, and system. The adaptive method explic- 
itly studies the unique relationships described above and uses these three links to build the 
first draft and incorporate user changes. 

This section touched upon the level of involvement and importance in the 
relationship between the user and builder. The next section deals with the important issue 
of the ways users should be involved in the DSS development and the role managers play 
in developing DSS falling under their span of control. 

C. MANAGEMENT ROLE IN DEVELOPING A DSS 

All managers are tasked with monitoring and reviewing projects under their control. 
A DSS is developed to provide decision support for a specific manager or group, and con- 
sequently falls under the control of those supported by the DSS [Hogue 83]. Keen states 
that a DSS is built from a manager’s perspective based on his conception of the decision 
process and organization [Keen 80]. Therefore, it is important the user/manager is actively 
and constantly involved in the control and development process of a DSS. 

1. User/Management Involvement 

Within an organization, usually one person or department recognizes informa- 
tion needs and that a DSS may satisfy these information requirements [Young 84]. Young 
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points out it is essential that an individual knows a DSS can provide decision support for 
the organization and the individual is in a management position to power the decision to 
develop the DSS. 

As suggested in the iterative and adaptive design methodologies, the develop- 
ment effort should be a constant feedback loop between user and builder. The user must be 
involved from inception to delivery to ensure user requirements are satisfactorily met and 
critical information needs are satisfied [Hogue 84]. A study of 18 DSS by Hogue and 
Watson revealed that management control by the requesting users was accomplished 
through user involvement, review of developed products, and documentation [Hogue 83]. 
Review points were established for the user to review, approve, and document the product 
as it was submitted iteratively by the builder. As the DSS moves toward completion, users 
provide a constant source of input and review. It would appear that the more users are 
actively involved in the DSS development, the more the DSS will be accepted. Users will 
develop an “ownership” in the DSS and aid in the development effort. User expectations 
will be managed better in that the user will periodically review DSS progress and witness 
how the DSS will incorporate user requirements. The proposed method of user involve- 
ment at SBHACH, which is a combination of the iterative and adaptive design methodolo- 
gies, will be discussed in Chapter HI in more detail. 

D . ARCHITECTURE OF A DSS 

So far in this chapter, less tangible DSS concepts have been presented, such as how 
DSS will aid decision makers, how decision makers should be involved in the DSS devel- 
opment process, and the structure of management problem areas best addressed by a DSS. 
It is now important to describe the more tangible components comprising a DSS and how 
these components interact. Figure 2-7 presents the three components of a DSS [Sprague 
82]. 



21 




Figure 2-7. DSS Sub-Components 



As shown in Figure 2-7, the user accesses the DSS through a dialog interface which 
drives the system by chauffeuring the decision maker through data extraction from 
databases, data manipulation by models, and presentation of results for decision making 
[Sprague 87]. By breaking a DSS down into the database, modeling, and dialog compo- 
nents, a builder can identify the requirements each component must possess to construct a 
DSS. 

1. Database Component 

The evolution of database technology in the past decade has made the addition 
of this component possible for use in a DSS integrated with the other components. The 
growth has moved from performing transaction processing and file management to adopt- 
ing a database management approach with query languages to provide ad hoc reporting 
[Sprague 87]. 
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a. Description 



Decision makers often rely not only on internal data but on external data as 
well. The database component must extract and manage data from both sources as neces- 
sary to support user information requirements. 

The database component must provide memory storage for extracted data 
prior to use, and data generated as output from modeling components. These storage and 
retrieval functions should be fast and transparent to the user [Sprague 82]. Another 
important characteristic the database component should possess is the ability to act as an 
intermediary between different models. The output from one model may be stored and 
used alone or combined with other model outputs as inputs to a second model and so on. 

The data extraction system shown in Figure 2-8 [Sprague 82] functions as 
a data reduction tool to screen out superfluous data. It also serves to simplify the design of 
the DSS as well as collect and maintain data for use by the DSS. The separation of 
operational and DSS databases allows faster incorporation of added user requirements and 
responses to unanticipated requests [Sprague 87]. Chapter IV describes the databases that 
will need to be created making up the database component of the DSS for SBHACH. 




Figure 2-8. DSS Sub-Components With Data Extraction System 
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2. Modeling Component 



The power of a DSS relies upon its ability to integrate data with models to 
manipulate information into a form useable by decision makers. The modeling component 
is discussed to introduce the concept of modeling and the way modeling plays an important 
role in decision support. 

a . Description 

As described earlier, the database component provides access to the large 
amount of raw data necessary for decision making. However, it is the modeling compo- 
nent that gives decision makers the ability to analyze this raw data [Sprague 82]. The 
modeling component acts as a tool to manipulate data into a meaningful form for decision 
makers. Sprague and Carlson suggest the modeling component 

provide a set of mechanisms for the use of decision/analysis models which draw on 
the data base and are closely related to it It must also provide the dialog mechanisms 
for the decision maker to interact with the data and models in a convenient, supportive 
manner. [Sprague 82] 

Use of model output as other model input was mentioned earlier. Each 
model usually requires data in its own format and supports only one distinct phase of deci- 
sion making. It is important that the model component maintain a model base that contains 
a library of models. Models that are generic can be used repeatedly by the DSS and other 
DSS [Gorry 71]. Users find generic models easier to use due to the familiarity that comes 
with frequent use. A decision maker should be able to combine different models in a man- 
ner to manipulate data in support of a variety of decision problems. 

Barbosa and Hirko present four characteristics that modeling components 
should possess [Barbosa 80]. To provide an enriched tool to the DSS, modeling should 
possess the following: 

♦ System interfacing; 

• User control; 
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• Flexibility; 

• Feedback. 

Interfacing allows the user to move in the DSS problem-solving environ- 
ment without the needless interruption of interactively supplying too many parameters and 
variables to different models. The control the user should possess is found in manual ver- 
sus automatic modes of operation. The user can manually select the algorithmic operation 
necessary to perform desired functions and operate in the modeling system as slowly as 
necessary to learn operating skills. By combining manual with automatic user operation, 
the modeling component will possess the flexibility necessary to flow outputs of one model 
as inputs to another in order to achieve desired results. Finally, feedback to the user is 
necessary to maintain control over the modeling process. The feedback should inform the 
user what state the solution generation is in at all times [Barbosa 80]. 

Brennan and Elam noted that modeling for DSS use has progressed at a 

modest rate and the emphasis must be put into “smart” modeling [Brennan 85]. The DSS 

must have a user interface when viewing the results of the model in an environment or 

framework that makes sense to the user. The interface must not only provide the results 

from model manipulations but also answer the question “Does the model produce sensible 

results?” in order to gain the trust of DSS users. Sprague and Carlson echo this finding by 

describing the lack of trust DSS users experience with large complex models. 

Decision makers do not put a great deal of faith in the results of complex models they 
do not understand the workings of, and major decisions may not be entrusted to 
modeling components if this trend prevails. [Sprague 82] 

Although modeling is a vitally important function in manipulating large 
amounts of data, it is virtually transparent to the user. The dialog component, although just 
as important as modeling, is not transparent and is always in plain view of the DSS user. 
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3. Dialog Component 

The last component of the DSS, the dialog component, is vitally important in 
that the user sees this feature of the DSS most often and forms opinions of like or dislike of 
the system as a whole based on this interaction. This component provides the DSS user 
interface. According to Keen, “from a user’s perspective, the quality of the DSS largely 
depends on the quality of the dialog.” [Keen 80] To foster flexibility of DSS use, the dia- 
log component should cater to both novice and experienced users [Sprague 80]. This 
flexibility is important due to the turnover rates and shuffling of personnel common in mil- 
itary units. The DSS should provide the capability of guiding the novice user through the 
system when the user is changed to a new job using a DSS or temporarily filling a position 
for a short time. 

a. Description 

The dialog component can be broken down into three elements that 
collectively make up the system interface of the DSS. As shown in Figure 2-9 [Sprague 
80], the dialog component is made up of the action language, the presentation language, 
and the user knowledge base [Bennet 77]. 

The action language is the hardware and software capabilities the system 
incorporates for the user to communicate to the DSS. It may consist of a keyboard, mouse, 
light pen, voice command, or other means necessary for the DSS to be used. The devel- 
opment of the action language should be dependent on user input skills with various hard- 
ware methods. The existing hardware and software within the organization must also be 
taken into account if the DSS is to be developed to run on those components. 

The presentation language is the means by which the output is displayed 
to the user of the DSS. It is the method by which the output is written or graphically dis- 
played on the computer screen. The presentation language is an important aspect of the 
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system because users have different cognitive styles. The importance of realizing this style 
difference and not attempting to incorporate user cognitive style in a DSS is discussed later 
in this chapter. 
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Figure 2-9. The User System Interface 



The knowledge base is what the user must know to operate the system. 
This knowledge base may be inherent to the user or in a user manual, help keys, or note 
cards. The success of a DSS is often evaluated by whether it is used. Developing a dialog 
component that is easily understood and useable by novice and experienced users alike will 
produce a product that will be used by decision makers. 
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b. Constructing the Dialog Component 



When developing a DSS for an organization, it is important to factor in the 
three elements of the dialog component for analysis. This is done by a skilled analyst 
through interviews and studies of existing databases and hardware components. After 
analysis is complete, the DSS builder should have an idea of the skill level DSS users pos- 
sess and what hardware will be available to run the implemented DSS. 

At the completion of interviews, the DSS builder will have a framework 
from which to develop the action and presentation languages. The action language can be 
determined early in the development process by studying decision makers at work with 
existing computer resources and taking informal surveys of skill levels. The hardware on 
which the DSS will operate often dictates the extent of the action language to be used. 
Determining the actual information to be presented to the decision maker determines the 
mode in which the information will be presented. If DSS users require a variety of infor- 
mation for forecasting and comparing trends within sub-units of the organization, then 
graphic capabilities will be required. Presentation requirements are addressed later in this 
chapter. Interviews are a good source for identifying how much the knowledge base 
should rely on the user and how much should be incorporated internal to the DSS and 
documentation. 

Using an iterative approach by developing a small sub-problem of the 
DSS and submitting it to the user for his critique will have a positive effect on the develop- 
ment of the DSS. Primarily, it will provide a walk-through using sample input and output 
so the user becomes familiar with what the DSS will be like. The second effect is testing 
the user under field conditions. The builder can actually observe the user and find out 
where problem areas exist (e.g., data entry error rates) and make adjustments to the dialog 
component accordingly [Sprague 82 ]. 
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Sprague and Carlson list several examples of dialog styles that could be 
employed by a DSS [Sprague 82]. These examples range from the basic one-line-at-a-time 
question-answer dialogs (Q/A), to progressive menu selection dialogs, to more complex 
command language dialogs. The development of the dialog component should thoroughly 
investigate which dialog style will best suit the DSS. 

Q/A dialogs lead users through the system by presenting a series of ques- 
tions that narrow down the scope until the desired information view is found. Menu-driven 
dialogs lead the user through different possible options available until the desired informa- 
tion view is obtained. Figure 2-10 provides an example of the menu dialog. In this figure, 
the user is offered one of four options. A selection of menu options one, two, or three will 
present the user with another menu option screen. This method guides the user through the 
different menu choices until the desired view of the data is found. Command language 
dialogs involve memorizing a series of verb-noun pairs (a command) which is typed into 
the computer to invoke a DSS function. For example, CALC MCCU will calculate the 
Medical Care Composite Units (MCCUs) over a given period of time. 

PLEASE CHOOSE THE NUMERIC OPTION CORRESPONDING TO 

YOUR DESIRED MENU SELECTION. 

1 . Calculate Medical Care Composite Units (MCCUs). 

2. Graph historic Medical Care Composite Units (MCCUs). 

3. Perform Medical Care Composite Unit (MCCU) sensitivity analysis. 

4. Exit the DSS. 

PLEASE CHOOSE A NUMERIC OPTION 1 TO 4 ... 



Figure 2-10. Sample Menu Option Display 
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In determining the appropriate dialog level, one factor considered often is 
frequency of use. The frequent user will eventually find the Q/A dialog style tedious and 
prefer the command dialog. Conversely, the infrequent user will see the Q/A dialog more 
accommodating since the command language dialog involves constant relearning of com- 
mands. Given the current problem environment, both user types could be expected to use 
the DSS. The menu-driven method should combine the respective advantages from the 
Q/A and command dialog styles that would benefit users. A number of alternatives are 
presented to the user on screen. Selection is made from these on-screen choices, thereby 
eliminating the need to memorize commands and the line-by-line process. A hierarchy of 
menus could be devised to provide a wide range of alternative displays. 

The analysis of an organization to determine the content of the DSS archi- 
tecture requires a substantial allotment of time and other resources. Managers need some 
type of tool to determine whether construction of a DSS be undertaken. The next section 
addresses the method to be used in justifying this construction. 

E. JUSTIFYING A DSS 

Although costs for computer hardware have been decreasing in recent years, alloca- 
tion of funds for capital ventures such as computer systems still require a significant outlay 
of resources for most organizations. For a computer system to be designed, built, and 
maintained, some method of quantifiable payback is required. Historically, cost-benefit 
analysis is a tool used to choose between competing capital decisions by eliminating unde- 
sirable projects and highlighting projects that can be successfully undertaken. 

1. Cost-Benefit Method 

The cost-benefit method, although relevant for most system projects, is not well 
suited for DSS [Keen 81]. For this reason, the value analysis method is presented as an 
alternative to the cost-benefit method. As Keen points out, DSS provide benefits that are 
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qualitative and not quantitative. The key failure of using the cost-benefit method to evaluate 
a DSS is the inability to match associated costs and benefits to the proposed DSS. 

The cost portion of a DSS is difficult to accurately pin down. How does one 
separate the different costs associated with a manager’s time? The question asks “How 
much should be charged to building the DSS with regard to the cost of a manager’s time 
used while conducting interviews and iterative reviews of the DSS?” Also involved are 
costs associated with sharing existing computer hardware and databases the DSS will 
require. What is a “fair share” of how much of the existing hardware the DSS will use on a 
daily basis? This percentage is difficult to predict prior to building a DSS. 

Hogue and Watson point out that “many DSS are never finished but, continu- 
ously evolve [Hogue 84].” This brings out the question of what the costs will be with ad- 
ditions to the DSS and how these costs will be factored into the analysis. 

Benefits also present a problem to managers. The benefits a standard computer 
system gives to an organization are quantifiable, while the benefits a DSS provides are 
mostly qualitative in nature. Keen presented examples such as viewing more alternatives 
prior to decision making, generating new ideas, and increasing communication of analysis. 
Managers examining potential benefits of a DSS cannot easily quantify these features for 
comparison against competing capital decisions. Another approach for analyzing the value 
of a DSS is required. This approach is the value analysis method. 

2. Value Analysis 

Keen states that value analysis proposes a systematic means of determining if a 
cost is justified on a product by concentrating on the following: 

• Value first then cost; 

• Simplicity and robustness; 
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♦ Reduction of uncertainty; 

♦ Innovation. 

This method allows projects to be analyzed that would otherwise be elimi- 
nated — it focuses on the estimates decision makers will have to provide to the DSS and 
how well it reduces the risk of the situation and adds innovation rather than imposing 
structure [Keen 81]. 

An approach focusing on the four elements presented above is used to develop 
the DSS. Developing a working subset of the DSS by incorporating a few of the user 
requirements shows the user what benefits he will gain from the system and relates these 
benefits to a dollar amount spent. Decision makers can roughly interpolate the cost of the 
entire system, compare this cost with the benefits, and determine whether the development 
effort should proceed. This methodology is easily incorporated with the iterative and 
adaptive DSS building techniques and promises to deliver a product for an acceptable cost. 

F. COGNITIVE STYLES OF DSS USERS 

As alluded to in DSS architecture, the presentation language the DSS uses may influ- 
ence the user’s decision-making process. This section of the chapter will present two 
important points for discussion that should be considered when designing a DSS. The two 
points are (1) inconsistency of cognitive styles between individuals, and (2) the effects of 
presenting statistics and facts to users in relation to decision making. 

Designing a DSS to incorporate a user’s cognitive style, as attractive as this may 
seem, is not recommended by researchers [Huber 83 and Mann 86]. There are a number of 
reasons for not tailoring a DSS to fit the cognitive style of the user, primarily the erratic 
cognitive styles between individuals. 
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1. Inconsistency of Cognitive Styles 



Miller points out that individuals, when presented with problems and alterna- 
tives, tend to recode or restate the presented information into a form that makes sense to the 
individual [Miller 56]. This reverbalization tends to draw upon the individual’s own per- 
sonal history and past experiences, thereby influencing what he perceives the problem to 
be. It is possible then that two different individuals observing the same information can 
draw very different conclusions. This inconsistency between individuals does not lend 
very well to testing an individual’s cognitive style and incorporating it into a DSS. 

Not only do inconsistencies exist between individuals, but inconsistencies 
within the same individual are evident when faced with different types of decision problems 
[Dickson 77 and Huber 83]. Their research indicated that the same individual has a differ- 
ent cognitive style when faced with a different type of decision. This implies that to incor- 
porate a decision maker’s cognitive style would require an analysis of his cognitive styles 
across different decision problems. 

Although it is unwise to incorporate cognitive styles into a DSS, other options 
are available from hardware and software components that improve the overall decision- 
making quality. Using different dialog methods — user-guided or system-guided meth- 
ods — can support novice users and experienced users. A series of experiments studying 
the impact of user-guided or system-guided dialogs on novice and experienced computer 
users supported this point [Benbasat 81]. Novice users had problems with the user-guided 
dialog and felt a need to be chauffeured by the system-guided dialog. This indicates a need 
for both system- guided and user-guided techniques within the dialog component of DSS. 

The ability of DSS to provide different types of graphics to users is important. 
Benbasat’s study also showed that although graphical reports decreased the accuracy of 
reported data, subjects tended to request these reports prior to decision making. Results 
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showed that, regardless of cognitive style of the subjects, data in graphical form will be 
widely requested from a DSS. It may therefore be important to design a DSS to show the 
same data in different graphical forms to better enhance user understanding and decrease 
possible misperception of data presentation across a variety of users. 

2. Statistic Presentation Effects 

A study by Tversky and Kahneman demonstrated the effect framing decision 
problems in different manners had on the selection of alternatives. They showed that the 
relative attractiveness of options varied when decision problems were framed in different 
manners [Tversky 81]. By framing options in a confusing manner, it is possible that deci- 
sion makers may select an option they would normally not select. One of their studies dealt 
with allowing subjects a chance to choose between options that had probabilities of making 
a profit. By wording the options in a confusing manner, subjects were selecting options 
they would not normally choose. It is important when developing a DSS that alternatives 
are framed in an intuitive manner, in terms decision makers are familiar with. 

The limited ability of humans to process information is important to consider 
when designing the presentation language of a DSS. Miller uses the “magical number 
seven plus or minus two” as a general rule [Miller 56]. He points out in his article that the 
human is capable of processing a limited amount of information at one time. In presenting 
menu options to users, a point of diminishing memory capacity is reached. Miller suggests 
that option presentation be kept near the number seven. 

Another related experiment conducted by Benbasat dealt with the length of 
command words to use in an interactive dialog. The study was done to determine the effect 
different lengths of command words would have on two groups of subjects. One group 
used command words that were lengthy but was allowed to abbreviate them whenever 
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possible. The second group used abbreviated command words and was encouraged to type 
out the full word when group members were unfamiliar with the abbreviation. 

The experiment yielded two results. The group using the longer command 
words had a tendency to abbreviate the commands as group members became familiar with 
the computer dialog. The second group (using abbreviated commands) preferred to type 
the command word in its entirety when group members were unfamiliar with the computer 
dialog [Benbasat 81]. If lengthy command words are incorporated in the user dialog, 
abbreviation should be allowed to cater to users familiar with the system. If abbreviated 
command words are used, they should be long enough for novice users to easily under- 
stand their meaning. 

G. SUMMARY 

In this chapter, a framework was established to aid the reader in developing an 
understanding about decision support and DSS. Concepts vitally important to the research 
were presented to provide a clear understanding of the characteristics and purposes of a 
DSS, and how to analyze, design, and build a functioning DSS. 

Characteristics and definitions of a DSS were cited from several prominent 
researchers. The overall consensus was that DSS aid decision makers in confronting ill- 
structured problems using models and data analysis. The aid DSS users received was the 
enhancements of computer technology and, more importantly, the greater understanding of 
the decision problem. 

Two methods of planning and building a DSS were presented as an alternative to the 
systems development life cycle method. The iterative and adaptive methods, although 
focusing on different aspects of the decision-making environment, had very similar meth- 
ods for developing a DSS. These similarities particularly concentrated on constant 



35 



involvement of the DSS user. Sub-problems of the DSS were developed and presented to 
the user for review. This feedback method was repeated until a working DSS was refined. 

This chapter most importantly presented the three components of the architecture of 
DSS. The data, dialog, and modeling components are described in Figure 2-11, which will 
be used in Chapter IV to develop the DSS components. These components provide a con- 
cise schematic of the DSS structure for the author to systematically begin analysis and 
design. Chapter II provided the necessary guidance to analyze, design, and build a DSS. 
Chapter III will discuss the analysis phase of the SBHACH DSS. 




Figure 2-11. DSS Component Diagram Expanded 
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III. DERIVATION OF CRITICAL SUCCESS FACTORS 



A framework for analyzing and designing a Decision Support System (DSS) was 
developed in Chapter II. The purpose of this chapter is to present the derivation of Critical 
Success Factors (CSFs) for Silas B. Hays Army Community Hospital (SBHACH). The 
organizational setting of SBHACH is presented with emphasis on how the proposed DSS 
will support hospital managers. The methodology used to collect CSF data from hospital 
managers is described and the derivation of organizational CSFs from collected data is dis- 
cussed. Finally, the findings of the CSF methodology are presented, consisting of a dis- 
cussion of each hospital CSF and proposed measures for satisfying the CSF. 

A. SETTING 

In order to gain an appreciation for the breadth and complexity of the management 
task facing the Hospital Commander and his staff, it is necessary to understand the organi- 
zational structure of SBHACH. This section describes the mission of SBHACH, dis- 
cusses the chain of command, and discusses the current methods administrators use to 
manage hospital resources, including a description of existing Management Information 
Systems (MIS). As presented in Chapter II, DSS are best justified and tailored to support 
upper-level managers. This section also identifies the specific upper-level management 
positions in the hospital chain of command that will be supported by the proposed DSS 
(Resource Management DSS). 

1. Mission of SBHACH 

The mission of SBHACH is to provide quality health-care services to autho- 
rized personnel within the Fort Ord Health Services Area. This includes inpatient and out- 
patient medical treatment to active duty and retired personnel, their dependents, and other 
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personnel as authorized by the Department of the Army [Army Reg 40-3 85]. This broad 
mission statement neatly summarizes the purpose of SBHACH, but accomplishing this task 
requires the combined efforts of many skilled health-care providers and resource managers. 

2 . Chain of Command 

Figure 3-1 [Army Reg. 40-3 85] depicts the organizational structure of the 
major internal departments of SBHACH. The operational clinics and wards, consisting of 
the departments of medicine, surgery, psychiatry, etc., are consolidated under the Deputy 
Commander for Clinical Services, who reports directly to the Hospital Commander. Each 
operational department is responsible for providing diagnosis, care, and treatment in its 
respective field of medicine. The Clinical Support Division aids the Deputy Commander 
for Clinical Services by providing budget planning, coordination, preparation, and 
supervision [Army Reg 40-3 85]. 

The Deputy Commander for Administration also reports directly to the Hospital 
Commander and is the principal staff advisor to the commander on management and 
administrative matters. Reporting to the Deputy Commander for Administration are several 
miscellaneous divisions providing administrative record keeping, information reporting, 
and data processing support, including the Resource Management Division. The Resource 
Management Division is a primary source of information the Deputy Commander for 
Administration uses to administratively monitor key areas within the hospital. 

3. Current Resource Management Methods 

SBHACH has several existing MIS in place that contain data essential to pro- 
viding resource managers with needed decision-making information. This data and data 
from prepared reports are not readily useable; they require processing prior to presentation 
to decision makers. The current method of obtaining needed data from the various 
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Figure 3-1. Silas B. Hays Army Community Hospital Chain of Command 



functional areas of the hospital is to extract data available from the different MIS and 
prepared reports, manipulate the data into a useable form, and present the data to decision 
makers for analysis. When faced with decision problems, resource managers analyze these 
reports and MIS output for needed information. This section provides a description of the 
different MIS at SBHACH which currently provide data to decision makers. 

a. Automated Quality of Care Evaluation Support System (AQCESS) 
Management Information System 

The AQCESS MIS is a relatively recent addition to the hospital, having 
just been implemented at the first of the year (1988). “Bugs” are still being worked out, 
but it is still useful. The AQCESS system runs on a DEC 1184 computer and provides 
information to all clinics about patients and health-care providers. Each clinic is provided 
with a separate terminal accessing the DEC 1184 mainframe. The system provides quanti- 
tative information about the health-care services provided by health-care providers and the 
inpatients receiving these services at SBHACH. 



39 









The AQCESS system has three modules: appointment scheduling, 
quality assurance, and patient data. The appointment scheduling module is a decentral- 
ized appointment scheduling system that is slowly replacing the existing centralized 
appointment scheduling system in the hospital. The appointment scheduling module allows 
the clinics to schedule their own appointments, schedule appointment referrals to other 
clinics, record appointments kept, record walk-ins, and provide printouts to clinics on 
future and past schedules. This module offers a number of views of data and may be 
broken down by patient, clinic, or health-care provider over varied time periods. Statistical 
information is provided by this module which is helpful in determining clinic and health- 
care provider workload levels. 

The quality assurance module is used to provide profile, monitoring, and 
general quality assurance reports. The profile reports give specific information on health- 
care providers. The information provided includes education history, personal and profes- 
sional credentials, and credential renewal lists. Also provided are historical listings of spe- 
cific patients and medical cases the health-care provider has treated. 

Monitoring reports are provided on both clinic and health-care providers. 
A general list of the types of health care provided, such as surgery, physical therapy, etc., 
is provided by clinic and identifies patients treated. Another important monitoring tool 
identifies by patient name if a specific health-care provider is delinquent in updating medical 
records. The last reports provided by the quality assurance module are general quality 
assurance reports. These reports summarize important data such as blood use, patient 
deaths, and readmission of patients. 

The third AQCESS module is the patient data module. This module pro- 
vides a comprehensive record of inpatient data throughout the hospital wards. The data is a 
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conglomeration of necessary information about inpatients and is used by the Patient 
Administration Division. 

The AQCESS system provides both routine and ad hoc reports. Some 
reports are provided every 24-hour period; specifically, the clinic schedules for the next day 
are routinely routed to all clinics. A smaller number of reports are requested on an ad hoc 
basis whenever specific information is required by resource managers [Appendix D]. 

b. Uniform Chart of Accounts Performance Expense Reports System 

(UCAPERS) Management Information System 

The purpose of the UCAPERS system is to collect and report on two 
Uniform Chart of Accounts data elements. The Uniform Chart of Accounts is a uniform 
accounting procedure established in 1979. This procedure makes all military hospital 
commands report on three types of accounting data in a consistent and uniform manner. 
The three types of data reported quarterly to higher commands are expenses, personnel 
usage, and workload statistics. The UCAPERS system reports personnel expense and 
usage data. 

The system records work performed by civilian and military health-care 
providers, stores this data, and submits it to Health Services Command (HSC) in a form so 
HSC can provide reimbursement of funds to SBHACH for health-care services provided. 

The system runs on Datapoint hardware connected on an Attached 
Resource Computer (ARC) network of microcomputers throughout the hospital. The 
importance of this MIS is that it is the basis for which output in the form of health-care ser- 
vices provided is related to input in the form of budgetary allocation [Appendix D]. 



41 



c. Standard Installation Divisional Personnel System (SIDPERS) 

Management Information System 

The SIDPERS MIS is a personnel information system keeping records on 
all assigned military personnel at the hospital. It is a personal computer system made by 
Burroughs Corporation that is deployable to remote sites. 

SIDPERS maintains records of military personnel assigned to SBHACH 
on a hard disk internal to the computer. The data fields contain standard data on each sol- 
dier as well as detailed information on education, training, sex, religion, next of kin, etc., 
that is necessary to the smooth functioning of military organizations. As information on a 
soldier changes, or personnel are deleted or transferred, the database is updated to reflect 
the correct information. 

Each working day, the changes occurring over the past day are copied 
onto a floppy disk and hand-carried to the SIDPERS on post at Fort Ord that maintains the 
database post-wide. SIDPERS software allows users to view the database in different 
ways. It possesses the capabilities of a relational database that is menu driven to provide 
quick access to data that satisfies some ad hoc queries. In addition to this function, 
SIDPERS also provides word-processing capabilities [Appendix D]. 

4. Application of Resource Management DSS 

The Resource Management DSS will be used to help upper-level managers deal 
with ill-structured problems in a manner better than the present resource management 
method. The Resource Management DSS will go a step beyond the MIS level of decision 
support described in Chapter II and will support specific managers in the hospital chain of 
command. The use of the MIS to support the Resource Management DSS is discussed as 
well as managerial positions using the Resource Management DSS. 
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a. Use of MIS to Support Resource Management DSS 



As described in Chapter II, there is a separation of information gathering 
and decision making that occurs with the use of MIS and DSS technologies. The informa- 
tion system is used to store and collect data. The decision-making system is the actual 
resource manager or managers tasked with analyzing the collected data, making predictions 
and drawing inferences from the data, assigning values from inferences drawn, and taking 
action [Mason 81]. 

MIS and DSS technologies separate the information-gathering and 
decision-making systems in different manners. Figure 3-2(a) [Mason 81] represents 
support an MIS lends to the decision process. The information system is tasked with 
storing, retrieving, and classifying potentially useful data for the decision-making system. 
The decision-making system then determines from which areas the data must be retrieved 
and makes these requests to the information system. Mason points out that it is not feasible 
for the information system to have the capability of retrieving all combinations and 
permutations of possible requests. Therefore, the decision system is tasked with gener- 
ating these requests, drawing inferences and predictions from delivered reports, assigning 
values, and choosing a course of action. Resource managers at SBHACH request data 
from the different MIS within the hospital to address specific problems. Data is then 
analyzed and a course of action is chosen. 

The Resource Management DSS for SBHACH will go a step beyond the 
MIS level and provide predictive information to decision makers. Figure 3-2(b) combines 
the ability to make predictions and draw inferences from the data. In this manner, the deci- 
sion-making system (people) can ask “What if?” questions and get appropriate, timely 
responses from the information system. The people then assign values to possible choices 
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Decision-Making System 



(a) MIS Support of Decision Process 




What if? 
^ Questions 



if-then 



Responses 




Information System 



Decision-Making System 



(b) DSS Support of Decision Process 
Figure 3-2. MIS and DSS Support of Decision Process 

and take action. The Resource Management DSS is designed to allow resource managers 
to readily access databases created by the DSS consisting of extracted data from the 
AQCESS, UCAPERS, and SIDPERS MIS. Resource managers can ask “What if?” ques- 
tions and project future trends based on historical data. From these responses to queries of 
the information system, the decision-making system can take action on values assigned to 
the different possible choices and choose a course of action. 

Chapter II also presented a DSS acting as an intermediary between the 
user and MIS. Figure 3-3 [Sprague 82] shows the data-extraction system taking needed 
data from the UCAPERS, SIDPERS, and AQCESS MIS and creating databases for use by 
the DSS. Some of the databases created will be used for providing routine information, 
while other databases will be temporarily created and discarded after use. Chapter IV 
describes the databases to be created to support the the Resource Management DSS. 
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Figure 3-3. DSS Sub-Components With Data Extraction System 
b. Managers Supported by Resource Management DSS 



The Resource Management DSS will support primarily managers in the 
Resource Management Division and the Clinical Support Division. The Resource Man- 
agement Division is responsible for providing a variety of services pertaining to the pro- 
gramming, budgeting, accounting, review, and analysis of overall resource usage. The 
Clinical Support Division is responsible for providing centralized administrative manage- 
ment support to all professional elements of the hospital [Army Reg 40-3 85]. 

The Clinical Support and Resource Management Divisions report directly 
to the Deputy Commander for Clinical Services and Deputy Commander for Administra- 
tion, respectively (see Figure 3-4). The importance of emphasizing this relationship is 
clear. The two divisions using the DSS can act as facilitators to their respective deputy 
commanders, who in turn advise the Hospital Commander. Managers in these divisions 
can operate the Resource Management DSS and provide answers to ad hoc requests as well 
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as routine queries. Figure 3-4 also served as a starting point when initially identifying 
resource managers that would provide information from which CSFs could be determined. 




Figure 3-4. Managers Supported by DSS 



B . METHODOLOGY OF CSF STUDY 

Although CSFs were introduced in Chapter I, a more in-depth discussion of CSFs is 

needed. This section also discusses the methods used to collect data to determine hospital 

CSFs and the way CSFs are derived from collected data. 

As a review, Bullen and Rockart describe CSFs as: 

the limited number of areas in which satisfactory results will ensure successful com- 
petitive performance for the individual, department or organization. CSFs are those 
key areas where “things must go right” for the business to flourish and for the man- 
ager’s goals to be attained. [Bullen 81] 
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The most difficult part of analyzing management information needs is eliciting what 
“key areas” of business activity are necessary to reach established goals [Rockart 82], 
CSFs give insight into the organization and aid in planning and developing information 
systems to support data requirements needed to monitor organizational CSFs. 

A review of the literature on CSFs identified seven primary sources of CSFs [Bullen 
81]. Table 3-1 lists these seven CSF sources, describes each source, and provides an 
example relevant to the health-care industry. Bullen and Rockart stress that each source 
should be investigated thoroughly in order to elicit all CSFs pertaining to an organization. 

1. Method of Data Collection 

Bullen and Rockart describe the use of structured interviews to identify “key 
areas” that managers need to monitor in order to be successful [Bullen 81]. Structured 
interviews of key resource managers throughout the hospital chain of command were used. 
Interviews conducted identified key areas important to SBHACH managers and discovered 
the information needs currently used or desired by administrators in order to satisfy these 
needs. Interviews of personnel tasked with operating the various MIS were also conducted 
as well as data collection in the form of participant observation. 
a. Upper Level Management Interviews 

The author conducted a series of structured interviews with upper-level 
managers at the hospital. A preliminary interview and six CSF interviews were conducted 
to collect data on the information requirements necessary to properly manage hospital 
resources. 

One hour-long interview was conducted in order to identify preliminary 
problem areas and determine whether a DSS could aid in solving these problem areas. The 
Chief of Resource Management Division and the Chief of Clinical Support Division were 
interviewed. 
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Six hour-long structured interviews were next conducted to identify spe- 
cific CSFs. A structured interview questionnaire developed as part of the thesis (Appendix 
B) was used to elicit the different CSFs by focusing on CSF primary sources identified in 
Table 3-1. The following personnel were interviewed in the order listed: 

• Nursing Methods Analyst 

• Chief of Patient Administration Division 

• Chief of Personnel Division 

• Deputy Commander for Administration 

• Deputy Commander for Clinical Services 

• Commanding Officer, SBHACH 

The top-down approach is a method described by Bullen and Rockart to 
move from an individual manager’s focus on business objectives to an information systems 
focus. In the course of the interview, the manager is encouraged to discuss his business 
environment, consisting of his strategies, goals, and objectives [Bullen 81]. Figure 3-5 
[Bullen 81] demonstrates that as the manager identifies the goals, strategies, and objectives 
that he holds within his sub-organizational element, he invariably identifies reports and 
sources of data that satisfy his information needs. From these reports and data sources, 
analysts are able to design databases and information systems that will provide managers 
with needed information to make decisions supporting his goals, strategies, and objectives. 

Bullen and Rockart also suggest that structured interviews start at the 
lowest level possible in the organizational level and work upward [Bullen 81]. After the 
researcher became familiar with the organizational structure and current information man- 
agement practices, structured interviews were conducted by starting at the lower levels and 
progressing upward. By starting at the lower levels, important knowledge was gained in 
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TABLE 3-1 



PRIMARY SOURCES OF CRITICAL SUCCESS FACTORS 

[based on Bullen 81] 



Primary Source 


Description 


Example 


1 . Industry 


Factors determined by 
the industry itself 


Quality of health care 
to patients 


2. Competitive 
Strategy and 
Industry Position 


Industry position in 
which die organization 
finds itself 


Surrounding communities’ 
expectation of health- 
care services 


3 . Environmental 


Areas over which the 
organization has very 
little or no control 


Fluctuation of patient 
levels 


4. Temporal 


Areas that become 
temporarily important 
for a period of time 


AIDS concern 


5 . Managerial 
Position 


The different factors 
that are important to 
different managers 
with the organization 


Accuracy and timeliness 
of lab results to the 
individual clinics 


6 . Internal and 
External 


Factors that are inside 
an individual manager’s 
sphere of influence or 
external to a manager’s 
control 


Clinic staffing levels 
are not controllable 
by individual clinic 
chiefs, but are control- 
lable by the hospital 
commander 


7 . Monitoring and 
Building 


A difference in classi- 
fication of whether a 
manager is more con- 
cerned with tracking the 
organization’s progress 
(monitoring) or planning 
the next move (building) 


Monitorin g — tracking 
seriously ill patients 

Building — analyzing 
plans to open a new 
inpatient ward 
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Figure 3-5. Manager’s Business Environment and Focus: 
Strategies to Information Systems 



order to become more comfortable in conducting interviews further up the hospital chain of 
command. Reports and databases were identified in the lower levels and the interviewer 
became more knowledgeable in the organizational workings and identified where data 
originates and how it is processed before finally getting to upper-level decision makers. As 
CSFs were discovered, it was found that the lower-level managers were an important 
source of identifying where data was extracted from and that higher-level managers were 
beneficial in prioritizing CSFs. 
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b. Information Management Personnel Interviews 

Three hour-long interviews were conducted with information management 
personnel responsible for the maintenance and upkeep of the many MIS in operation at 
SBHACH. The purpose of these interviews was to provide a description of the different 
MIS that maintain relevant data used by resource managers. 

c. Participant Observation 

The final method of data collection was participant observation. This 
data-collection method consisted of observing several information management meetings 
conducted by managers and by analyzing reports and databases throughout the hospital. 
The information management meetings provided a focus from which trends and directions 
of the development of organizational information technology could be studied. 

2. Derivation of CSFs 

Bullen and Rockart provide a methodology for deriving an organization’s CSFs 
from the data collected during structured interviews. The key to successfully determining 
organizational CSFs is in determining the individual manager’s CSFs. Each manager is 
interviewed, concentrating on the seven primary source of CSFs listed in Table 3-1 [Bullen 
81]. The emphasis is to ensure that all potential sources of CSFs are discussed to “leave no 
stone unturned.” The manager’s CSFs are then listed and prioritized. 

The next step described by Bullen and Rockart is the aggregation of individual 
managers’ CSFs. The researcher takes each manager’s CSFs and combines all CSFs into 
an organizational view. This aggregation is conducted with the focus on extracting the 
organization’s CSFs and prioritizing them [Bullen 81]. The next section will discuss the 
data collected and the organizational CSFs derived from the data. 
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C. CRITICAL SUCCESS FACTOR FINDINGS 



The previous section discussed the methodology of the CSF research, describing 
how CSF data were elicited from upper-level managers and how an organization’s CSFs 
are derived from individual manager CSFs. This section identifies the appendices summa- 
rizing the data discovered during structured interviews and presents the SBHACH CSFs. 

1. CSF Data 

The interviews conducted at SBHACH are summarized in Appendices A, C, 
and D. The positions of resource managers are identified, but the names of personnel 
interviewed were not included even though nothing inappropriate was discussed during 
interviews. These appendices served as documentation for the development of the 
SBHACH CSFs. 

The structured interviews conducted with upper-level managers are presented in 
a partitioned format. The interviews are separated by each individual manager and pre- 
sented in the order in which they occurred. Each interview is divided into the seven 
primary sources of CSFs, as shown in Table 3-1. Data discovered was placed into one of 
the primary CSF sources. Summaries of the six upper-level management interviews con- 
ducted at SBHACH are found in Appendix C. 

The interviews conducted with management information personnel are summa- 
rized by the type of MIS that the particular individual was responsible for maintaining. All 
detailed information about existing MIS at SBHACH was discussed during these inter- 
views, which are summarized in Appendix D. 

2. Presentation of CSFs 

An analysis of the data collected during CSF interviews indicated that 
SBHACH had four CSFs. These four organizational CSFs are the major concerns on 
which upper-level managers at SBHACH must focus their attention. The four CSFs are 
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presented in this section, along with proposed measures the Resource Management DSS 
should be able to provide in order to satisfy information needs. Also discussed are project 
requirements that are of an information systems focus which the Resource Management 
DSS should also provide. 

a. Critical Success Factor 1: Maintain Sufficient Fiscal Resources to 

Meet the Demands For Inpatient and Outpatient Health-Care 

Services 

Medical Treatment Facilities (MTFs) were established to provide medical 
care to authorized DOD personnel and their dependents. Although these MTFs are non- 
profit oriented, they still must somehow account for the large expenditures of funding pro- 
vided by DOD. Health Services Command (HSC) must monitor these MTFs and provide 
funding in relation to some quantifiable measurement of services rendered by the individual 
hospitals. 

The current trend is for MTFs to be reimbursed relative to the health-care 
services that they provide [Appendix A]. HSC closely monitors each hospital, measures 
their expenditures in health-care services rendered, and reimburses them in relation to this 
expenditure. 

The current system of reporting to DOD the amount of health-care services 
provided by the MTF is based on a unit called a Medical Care Composite Unit (MCCU). 
When health-care providers (doctors, nurses, lab technicians,...) provide services to 
patients in the form of consults, surgery, pharmaceutical prescriptions, bed space, radiol- 
ogy, and other varied services, the MTF is credited with MCCUs depending on the type of 
service. For example, an outpatient visit is worth roughly 0.3 MCCUs, a live birth is val- 
ued at 10 MCCUs, and admission as an inpatient is worth 10 MCCUs the first day and 1 
MCCU every day thereafter. All health-care services provided are input daily by data entry 
clerks and maintained on a MIS. The information is updated daily, and weekly a tape is 
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run summarizing all health-care services provided by the MTF for the past seven-day 
period. A copy of the tape is sent to a DOD-run facility where the data is calculated into 
MCCUs. These MCCUs are used by DOD quarterly to provide monetary funding to 
SBHACH in reimbursement for health-care services provided at the MTF. A hard-copy 
report is forwarded to the MTF one month after the quarter has expired summarizing the 
MCCUs earned for the previous quarter [Appendix C]. 

The proposed measures of the Resource Management DSS for satisfying 
this CSF should maintain a productivity database that accurately provides performance and 
productivity criteria to resource managers that will do the following: 

• Compare current clinic work unit levels to historic values. 

• Forecast future clinical productivity using historic data and user-projected values. 

• Forecast future hospital productivity using historic data and user-projected values. 

• Compare current MCCU data to historical data and projected goals. 

• Project future MCCU values based on current trends of MCCU earnings and user- 
projected values. 

• Calculate unused capacity in the form of bed space and potential discharge 
information. 

• Calculate projected bed space required based on current trends. 

The system should also provide functions that are of an information sys- 
tems focus along with the DSS provided measures. The Resource Management DSS 
should also do the following: 

• Calculate monthly work units accomplished by individual clinics. 

• Calculate the number of MCCUs earned by the hospital to date. 

• Graph and chart work units accomplished over time for presentation to decision 
makers. 

• Calculate the entire hospital’s earned MCCUs each day to an acceptable degree of 
accuracy, and compare the moving average to projected goals. 
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b. Critical Success Factor 2: Maintain Sufficient Military and Civil- 
ian Personnel to Adequately Provide Health-Care Services to 
Fluctuating Inpatient and Outpatient Levels 

This CSF deals with properly staffing wards and clinics to meet the fluc- 
tuating demand of inpatients and outpatients. By providing an adequate number of health- 
care providers at varying levels of demand, the hospital will provide an acceptable level of 
medical care to all personnel authorized medical care at SBHACH. At present, civilian and 
military levels are tracked by the Personnel Division. When fluctuating patient levels and 
operational commitments overburden the staffing levels of wards and clinics, decisions 
must be made to reallocate health-care providers. Decisions must also be made when hiring 
civilians to replace vacant positions within the hospital [Appendix C]. 

The proposed measures for the Resource Management DSS satisfying this 
CSF are to maintain a manpower database to include all officer, enlisted, and civilian per- 
sonnel assigned to the hospital that will do the following: 

• Project gains/losses for six months in the future for military and civilian personnel. 

• Forecast clinical staffing levels from historical data and user-projected input. 

• Compare different clinical productivity levels at the same time. 

The system should also provide functions that are of an information sys- 
tems focus along with the DSS provided measures. The Resource Management DSS 
should also do the following: 

• Compare onboard count to authorized billets hospital wide as well as at the clinic 
level. 

• Maintain required qualification records on military health-care providers assigned to 
deployable forces. 
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c. Critical Success Factor 3: Monitor the Impact of the Primary Care 
to Uniformed Services (PRIMUS) Clinics and the Civilian Health 
And Medical Program of the Uniformed Services (CHAMPUS) 
Reform Initiative 

The two PRIMUS clinics being opened at The Presidio of Monterey and 
Salinas, California, are designed to provide health-care services to active duty, retired, and 
dependent personnel as an alternative to the medical treatment also provided at SBHACH. 
The medical care is provided mostly by civilian personnel under contract and covers small 
injuries, common illnesses, and general medical problems. Although the two PRIMUS 
clinics will duplicate a percentage of medical care that is already provided at SBHACH, 
there are certain medical services not rendered. 

SBHACH will still offer all medical services, but the PRIMUS clinics will 
take some of the workload from the hospital and give additional medical care to the sur- 
rounding military community. The PRIMUS clinics can have three effects on the hospital: 
they may “steal patients away” from the hospital and cause the overall hospital productivity 
to drop; they may increase the amount of patients treated through patient referrals; or the 
patient levels will remain the same. 

The CHAMPUS reform initiative is a program sponsored by HSC to 
retard the yearly costs of CHAMPUS, which currently are rising at a rate of 25 percent per 
year. In effect, the purpose of the CHAMPUS reform initiative is to identify a number of 
health-care providers outside the military hospital system who can provide medical care for 
the overflow of patients at SBHACH less expensively than their contemporaries. These 
health-care providers under contract will cost the government less in CHAMPUS costs then 
the current method of using more expensive outside medical practitioners [Appendix C]. 

The proposed measures for the Resource Management DSS satisfying this 
CSF are to maintain a database that contains the fluctuation of inpatient and outpatient 
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treatment during the opening of the PRIMUS clinics and the start-up of the CHAMPUS 
reform initiative that should do the following: 

• Measure the daily fluctuation of clinic productivity in work units compared to histori- 
cal values. 

• Forecast the number of outpatients in the future based on historical referrals from the 
PRIMUS clinics. 

• Measure the daily fluctuation of clinic MCCUs earned compared to historical values. 

• Project trends of outpatient drops due to loss of outpatients to PRIMUS. 

The system should also provide functions that are of an information sys- 
tems focus along with the DSS -provided measures. The Resource Management DSS 
should also do the following: 

• Monitor the number of patients treated due to referrals from the PRIMUS clinics. 

• Calculate the daily loss of MCCUs due to drops in outpatient levels. 

d. Critical Success Factor 4: Maintain a Sufficient Amount of Medical 

Equipment in Proper Working Order to Provide Necessary Health- 

Care Services to Inpatient and Outpatient Demands 

SBHACH makes significant budget expenditures on capital equipment 
each fiscal year. There are varying life cycles of different types of equipment, and occa- 
sionally the equipment does not last the entire life cycle and must be budgeted for earlier 
than expected. An important information requirement is to accurately project future 
requirements of equipment which will have to be planned for in the yearly budget 
[Appendix C]. 

The proposed measures for the Resource Management DSS satisfying this 
CSF are to maintain a database that tracks major items and contains records on cost, serial 
numbers issued, acquisition date, expected life cycle, anticipated expiration date, and other 
pertinent information. The proposed measure should do the following: 
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• Forecast future monthly budget expenditures on capital equipment based on historical 
data. 

• Forecast future monthly budget expenditures on capital equipment based on projected 
user input. 

The system should also provide functions that are of an information sys- 
tems focus along with the DSS-provided measures. The Resource Management DSS 
should also do the following: 

• Calculate total cost of the yearly budget portion allocated for the purchase of capital 
equipment. 

• Break down the equipment by functional wards and clinics and provide varied views 
of the database. 

• Identify equipment approaching the end of its useful life cycle. 

D. SUMMARY 

This chapter discussed the derivation of SBHACH CSFs in preparation for the design 
phase of the Resource Management DSS presented in the next chapter. This chapter also 
discussed the organizational setting of SBHACH, the methodology of collecting data for 
analysis, and, most importantly, presented the four CSFs derived from collected data. 

In discussing the organizational setting, the current method of resource management 
used by hospital administrators was presented. The three MIS used for data sources were 
presented in detail because these same MIS will be used by the Resource Management DSS 
to extract relevant data from. Finally, the actual managerial positions in the hospital chain 
of command which will use the Resource Management DSS were identified. 

The next section of this chapter discussed the methodology used to collect data. The 
three methods of data collection — upper-level management interviews, information man- 
agement personnel interviews, and participant observation — were presented. The person- 
nel interviewed were identified by their position within the organization. The importance of 
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the interviews is stressed because the CSFs for SBHACH were derived from this collected 



data. 

Finally, the organizational CSFs for SBHACH were presented in detail with the pro- 
posed measures which were developed to satisfy the information requirements of each 
CSF. Table 3-2 summarizes the four organizational CSFs derived from collected data. 
The next chapter will take a portion of these derived CSFs and design the first iteration of 
the Resource Management DSS. 



TABLE 3-2 

SBHACH PRIORITIZED CRITICAL SUCCESS FACTORS (CSFs) 



Priority 


Critical Success Factor 


1st 


Maintain sufficient fiscal resources to meet the demands 
for inpatient and outpatient health-care services. 


2nd 


Maintain sufficient military and civilian personnel to 
adequately provide health-care services to fluctuating 
inpatient and outpatient levels. 


3rd 


Monitor the impact of the Primary Care to Uniformed 
Services (PRIMUS) and the Civilian Health and Medical 
Program of the Uniformed Services (CHAMPUS) 
reform initiative. 


4th 


Maintain a sufficient amount of medical equipment in 
proper working order to provide necessary health-care 
services to inpatient and outpatient demands. 
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IV. DESIGN OF DECISION SUPPORT SYSTEM (DSS) 



Chapter HI discussed the analysis phase of the Resource Management Decision Sup- 
port System (DSS) at Silas B. Hays Army Community Hospital (SBHACH) in order to 
identify critical information requirements needed by resource managers. Chapter IV takes 
information found during the analysis phase and, using structured design tools, provides 
necessary documentation from which the first iteration of the Resource Management DSS 
can be implemented. 

As described in Chapter II, a small sub-problem of the DSS is agreed upon between 
user and builder. The builder designs a system and presents it to the user for feedback. 
The builder makes necessary corrections and repeats the process by building on the existing 
system [Sprague 86]. This first iteration of the Resource Management DSS will be pre- 
sented to users for review and will serve as the system’s cornerstone from which the full- 
scale Resource Management DSS can be constructed. 

In order to design the first iteration, a partition of the DSS analysis is made and the 
design of a sub-problem is conducted. This chapter discusses a portion of the Critical 
Success Factor (CSF) that will be designed from this partition. A transformation from 
analysis to design using structured specification and module specification tools is 
described. In addition, this chapter also describes the Resource Management DSS con- 
struction using the data, dialog, and modeling components presented in previous chapters. 
The delivered product from this chapter will provide follow-on researchers with sufficient 
documentation to implement the first iteration of the SBHACH Resource Management DSS 
in a structured programming language such as PASCAL. 
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A. SIZE OF FIRST DSS ITERATION (VERSION 0) 



Version 0 of the Resource Management DSS is limited to providing information and 
modeling capabilities to satisfy two of three proposed measures found in the first CSF. 
The first CSF is to provide information to decision makers in order to maintain sufficient 
fiscal resources to meet the demands for inpatient and outpatient health-care services. 

The two areas from the first CSF to be satisfied are Medical Care Composite Unit 
(MCCU) earnings and productivity trends. A discussion of these two areas will provide 
the reader with an understanding of the type of information required to satisfy a portion of 
the first CSF. 

1. Medical Care Composite Unit (MCCU) 

The Resource Management DSS must provide decision makers with daily and 
monthly MCCU earnings. The most recent 30-day earning of MCCUs can be extracted 
and graphed to display MCCU earning trends. Resource managers can also monitor the 
number of MCCUs earned by the hospital to date for the current fiscal year. 

A monthly database of the current and previous years’ MCCU earnings will 
allow the comparison of recent data to the previous year’s data. From this historical 
database, projections of the next six months’ MCCU earnings can be made based on recent 
trends using a moving average calculation formula. Also, users can input predictions for 
future months and project up to six months of MCCU earnings in the future. Graphics in 
the form of a spreadsheet application will plot the MCCU earnings and save desired data to 
files for later use. 

2. Productivity 

Productivity databases will provide information about individual clinics as well 
as hospital-wide in the form of work units earned in comparison to health-care providers 
assigned. For both the hospital and individual clinics, the last six months of monthly 
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productivity earnings can be graphed on a spreadsheet application and saved for future use. 
In addition to historical trends, productivity projections can be made based on the last few 
months’ earnings or based on the user’s predictions of future months’ productivity. 

B . TRANSFORMATION OF ANALYSIS TO DESIGN 

It is important to correctly transform the analysis into a system design. Page-Jones 
describes this procedure as taking the voluminous amount of information produced during 
the analysis phase and determining how to organize what it describes in a manner suitable 
for computer execution [Page-Jones 80]. 

The transformation of analysis to design is made in two steps. In the first step, the 
structured specification primarily uses three tools to logically describe the evolving system. 
The module specification is the second step and uses two tools to describe procedural 
detail. The by-products of these two design steps will provide sufficient documentation 
from which source code can be developed. 

This section will describe the structured specification and the module specification 
design steps. The tools used to transform analysis to design will be discussed and specific 
examples presented from the Resource Management DSS. Finally, the appendices con- 
taining documentation from this design phase will be referenced. 

1. Structured Specification 

A structured specification is used to allow the system builder to clearly under- 
stand the workings of a system and create a design quickly and accurately showing what 
the system will do [Page-Jones 80]. Page-Jones describes a structured specification as 
having the following characteristics: 

• Graphic and concise; 

♦ Top-down partitioned; 
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• Non-redundant; 

• Logical, not physical. 

In other words, the structured specification contains pictures rather than text 
[Page-Jones 80]. Graphical representations of data, data flows, and processes are better 
understood than textual descriptions. The structured specification breaks the system down 
into smaller, independent pieces for easier understanding. It is also non-redundant in that 
the structured specification records a piece of information only once for consistency and 
accuracy. Finally, the structured specification focuses on what the system will accomplish 
for the user (the logical) rather than on how the system will be implemented by a particular 
machine [Page-Jones 80]. 

The structured specification primarily consists of the following three tools: 

• Leveled Data Flow Diagrams (DFDs); 

• Tools to describe policy; 

• Data dictionary. 

Using structured specification tools will enable designers to easily create a 
description of what the system is performing. The remainder of this section will describe 
these tools. 

a. Leveled Data Flow Diagrams (DFDs) 

The DFD is used to partition a system and is desirable because it is 
graphic, concise, and non-redundant [Page-Jones 80]. DFDs consist of four elements: 
data flows, processes, data stores, and sources/sinks. Figure 4- 1(a) provides a sample 
DFD as it appears with all four elements. Figure 4- 1(b) shows a portion of the DFD from 
the Resource Management DSS. 

A data flow consists of data moving between processes, data stores, and 
sources/sinks. The name of the data flow is written beside the data flow and an arrow 



63 




(a) Data Flow Diagram Components 




(b) Sample Resource Management DSS Data Flow Diagram 

Figure 4-1. Data Flow Diagrams 
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indicates the direction in which the data are moving. According to Page-Jones, the data 
flow can be thought of as parts being delivered on a conveyer belt or a pipeline carrying 
pieces of data [Page-Jones 80]. 

A process is used to transform data in one of two ways. A process may 
transform the structure of data by reformatting it or may transform the information con- 
tained in the data [Page-Jones 80]. Note that in Figure 4- 1(a), data flows going into a pro- 
cess do not have the same names as data flows leaving the process because the data was 
somehow changed. Figure 4- 1(b) shows six different data flows coming into the process 
CALCULATE MCCUS and a single data flow leaving it. The six data flows coming in 
were used to generate a single data flow leaving the module. 

A data store is a temporary storage area for data to be used by the system. 
In essence, data stores are the created databases used by the Resource Management DSS 
from which to extract data. The data store DAILY MCCUS CURRENT FISCAL YEAR 
allows the daily MCCUs calculated each 24-hour period to accumulate. On request from 
the PLOT PAST THIRTY-DAY MCCUS process, the last 30 days worth of MCCUs are 
taken from the data store and delivered to the process. 

Finally, the last DFD sub-component is the source/sink. Sources and 
sinks are found on the edges of the DFD. They show where desired data originate and 
provide a final recipient of the finished product exiting the system [Page-Jones 80]. 

DFDs representing a system can be quite large and complicated, requiring 
a method of partitioning to separate the large DFD into understandable sub-components. 
The entire DFD is started by a context diagram indicated as level 0 and partitioned down 
through various layers until further partitioning is no longer practical. The lowest level 
processes are called functional primitives and are the building blocks of the context diagram 
[Page-Jones 80]. This top-down partitioning method will take a single process and will 
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show the details of that process in the form of a more detailed DFD. The small DFD 
portion found in Figure 4- 1(b) describes a single process found at the next higher level of 
the DFD. The numbering system is used to denote hierarchy — sub-elements from process 
1.0 are labelled 1.1, 1.2, 1.3, etc., clarifying details of larger processes. The input and 
output data flows from the superior process are the same for the subordinate sub-com- 
ponents. Appendix E contains the leveled DFD for the Resource Management DSS. The 
context diagram is presented first, and each process is leveled by describing it in terms of 
lower-level data flows, processes, and data stores. Appendix E presents a logical view of 
what the system is doing. The next section describes the method used to explain this 
graphical representation. 

b. Tools to Describe Policy 

Because the DFD shows partitioning of a system only, some method of 
describing each functional primitive must be used to specify the mechanics of the whole 
system. Mini-specifications, or simply, mini-specs, are used to describe each functional 
primitive. Only functional primitives are described because any other process is a con- 
glomeration of functional primitives and violates the non-redundancy rule of structured 
specification. Page-Jones points out that the goals and objectives of the mini-specs tool are 
to ensure the following: 

• There must be one mini-spec for each functional primitive in the DFD. 

• The mini-spec must state the way in which the data flows entering the functional 
primitive are transformed into the data flows leaving it 

• The mini-spec should control redundancy by not restating something already stated in 
the DFD or data dictionary. 

• The mini-spec should facilitate descriptions in a standard manner. [Page-Jones 80] 
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Mini-specs can be written in three ways: Structured English, the decision 
tree, or the decision table. Structured English is the method used to write the mini-specs 
for the Resource Management DSS and therefore is the only method described here. 

Figure 4-2 is a sample mini-spec of the functional primitive CALCULATE 
MCCUS taken from Figure 4- 1(b). The Structured English method describes what the 
functional primitive does to transform the data flows going into the process to the data flow 
leaving the process. Notice that the mini-spec uses verbs where possible and uses terms 
from the data dictionary which have a specific meaning [Page- Jones 80]. The mini- spec 
should be written to tell the programmer what is to be done rather than how to do it. 
Appendix F contains the collection of mini-specs explaining the functional primitives iden- 
tified from the set of leveled DFDs. 



1.1 CALCULATE MCCUS 

For the past 24-hour period do the following: 

1. Get number of admissions 

2. Get number of phone consults 

3. Get number of inpatients 

4. Get number of live births 

5. Get number of outpatient visits 

6. Get number of inpatient visits 

7. Calculate the number of MCCUs earned by: 

7.1 (Number of admissions) X ADMISSION_VAl plus 
72 (Number of phone consults) X PHONE_CONSULT_VAL plus 

7.3 (Number of inpatients - number of admissions) X CENSUS_VAL plus 

7.4 (Number of live births) X LIVE_BIRTH_VAL plus 

7.5 (Number of outpatient visits plus Number of inpatient visits) X CLINIC_VISIT_VAL 



Figure 4-2. Mini-Spec for Process CALCULATE MCCUS 
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c. Data Dictionary 

A data dictionary is the collection of all data elements that are found in the 
DFD, mini-specs, or even in the data dictionary itself. The data dictionary functions as a 
repository for the definition of all data elements. Data elements that are a combination of 
other data elements are further defined in the data dictionary until all data elements are 
described. The data dictionary is alphabetized to facilitate ease of use. Appendix G con- 
tains the data dictionary for the Resource Management DSS. 

2. Module Specification 

The second step used in designing the Resource Management DSS was the 
module specification. The module specification uses two tools — the structure chart and a 
written description of the function of each module. The goal of module specification is to 
take the DFD, which has very little procedural detail, and produce a structure chart which 
has a great deal of procedural detail. The structure chart, when accompanied by module 
specs, provides detail from which a programmer can develop source code [Page- Jones 80]. 
a . Structure Chart Transformed From DFD 

By carefully studying the DFDs, a structure chart is drawn that depicts the 
entire system. The structure chart is drawn to partition the system into separate and 
relatively independent modules. Each individual module is responsible for a certain action 
within the system and represents a reasonable partition of source code that will be written 
by the programmer. The structure chart shows the hierarchy of the modules and a simple 
description of each module is provided through its name. 

Figure 4-3 is a small subset of the Resource Management DSS taken from 
Appendix H. The module DO THIRTY-DAY TREND MENU CHOICE will contain the 
program source code that allows it to call on the subordinate module GET THIRTY-DAY 
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Figure 4-3. Portion of Resource Management DSS Structure Chart 



TREND MENU CHOICE. This subordinate module will present the user with a menu, 
read the user’s menu selection, check for valid input, and return the valid choice to the 
calling module (DO THIRTY-DAY TREND MENU CHOICE). Depending on the menu 
selection, this module will call upon either the PUT GRAPH OF THIRTY-DAY MCCU 
TREND module or the PUT MCCU EARNINGS TO DATE module. Supposing the for- 
mer module is selected, the source code in this module will call upon the GET MOST 
RECENT THIRTY-DAY MCCU EARNINGS module, which will extract the most recent 
30 days’ worth of daily MCCU data and pass it back to the calling module, where the data 
will be graphed. This modularization breaks the entire system down into smaller portions, 
facilitating source code development. The remainder of the Resource Management DSS 
structure chart is found in Appendix H. 

b. Module Specification By Module Specs 

Examining the structure chart alone will not provide the needed informa- 
tion from which a programmer will be able to derive source code. An explanation of the 
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individual module by module specs must be provided to give sufficient information to the 
programmer [Page- Jones 80]. Pseudocode is the most often used form of module specs. 

Pseudocode is a detailed method of describing a module that tells the pro- 
grammer how the module will perform its function. It is written in a Structured English 
format and can look very similar to the code itself. Figure 4-4 provides a sample of the 
pseudocode found in Appendix I documenting the Resource Management DSS. 

MODULE DO THIRTY-DAY TREND MENU CHOICE 

/ * Finds out what the user wishes to do with MCCU earning trends */ 

/ * Narrows choices to displaying MCCUs earned to date, graphing 
recent trends, or quitting the menu */ 

Get a valid menu pick 

If not quit then 

If request for recent MCCU earning trends 
then call module to graph thirty-day 
MCCU trend 

Else If request for MCCUs earned to date then 
call module to display MCCU earnings 
to date 

END MODULE 

Figure 4-4. Sample Module-Spec By Pseudocode 

C. DECISION SUPPORT SYSTEM (DSS) ARCHITECTURE 

The data, dialog, and modeling components of DSS architecture are also a convenient 
method of partitioning a DSS for design. The system specifically addresses the three major 
components of a DSS for designers to construct individual system requirements. The 
Resource Management DSS is described in this section by focusing on the data, dialog, and 
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modeling components. Each is described in detail and construction requirements are 
discussed. 

1. Data Component 

a . Description 

The data needed to support the Resource Management DSS design will be 
extracted from a variety of reports and MIS in the hospital. At present, the proposed data 
extraction method consists of information systems personnel setting up the required data- 
bases in support of the the Resource Management DSS and assigning a database adminis- 
trator. The context diagram of the DFD found in Appendix E identifies the different 
sources of necessary data. The database administrator will maintain the required databases 
to support the Resource Management DSS. 

During the analysis phase, redundant sources of data elements were dis- 
covered. Many data elements identified in the locally generated reports were also found in 
the hospital MIS. The locally generated reports could be replaced by hospital MIS once 
data accuracy is verified. Using hardware to automatically extract data from the hospital 
MIS was not investigated for feasibility. The procedures and programs to perform the 
extraction of data are left for future research. 

b. Construction 

Four separate databases must be set up to support the first iteration of the 
Resource Management DSS: Two MCCU databases and two productivity databases will 
have to be established in order to provide a source of current MCCU and productivity 
information. 

The first MCCU database, DAILY MCCU ANALYSIS FILE, will consist 
of MCCU earnings of the hospital each day for the current fiscal year. Daily MCCUs must 
be calculated and added to the database each 24-hour period. The maximum number of 



71 



days’ worth of data will be 365 days and the minimum 30 days. In order to calculate the 
most recent 30-day MCCU earning trends, this database must have as a minimum the last 
30 days’ daily MCCU earnings on file. 

The second MCCU database, MONTHLY MCCU ANALYSIS FILE, is 
composed of the entire hospital’s monthly earnings of MCCUs for the current and previous 
fiscal years. As a maximum, this database will have 24 months of data and as a minimum 
it will contain 12 months of data. 

The two productivity databases will require the past 24 months’ produc- 
tivity data by individual clinics as well as hospital-wide. The CLINIC PRODUCTIVITY 
ANALYSIS FILE will maintain the past 24 months’ worth of productivity for each clinic in 
terms of monthly work units accomplished divided by the average number of health-care 
providers in the clinic that month. Productivity will have to be calculated and added to the 
database as the monthly totals become available. As another month is added, the oldest 
month can be deleted from the database. 

The HOSPITAL PRODUCTIVITY ANALYSIS FILE will contain the 
hospital productivity values for the past 24 months in the same manner as the clinical 
database. The most recent 24 months’ worth of productivity will be kept. 

2. Dialog Component 
a . Description 

The importance of the dialog component cannot be overstated. If the 
interaction between the user and DSS is difficult, the DSS will most likely fall into disuse. 
The dialog component of the Resource Management DSS was analyzed in terms of user 
computer experience and estimated frequency of use. During interviews, levels of com- 
puter experience were discovered from potential users and a dialog method commensurate 
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with this skill level was determined. A menu-driven dialog was chosen that would guide 
the Resource Management DSS user through the different levels of the system. 

The choice of a menu-driven dialog was made because this allowed 
resource managers not experienced with computers to easily learn and use the system. A 
menu-driven dialog will also alleviate the requirement of learning and relearning complex 
commands by infrequent system users and new users alike. The implementation of the 
Resource Management DSS should be flexible enough to use a menu-driven dialog com- 
bined with an interactive query type of dialog when necessary. 
b. Construction 

The menu-driven dialog will be constructed to provide a reasonable num- 
ber of menu options (the magical number seven plus or minus two) so as not to overburden 
the user’s capacity to process information [Miller 56]. A menu-driven dialog will guide the 
user through the various levels of the Resource Management DSS. Where appropriate, 
simple choices are selected from the menu, or the user is queried for input. 

An example using the menu-driven dialog style is getting subjective pre- 
dictions of future months’ MCCU earnings. The menu-driven dialog will guide the user to 
the level of selecting the option of forecasting future MCCU earning trends based on the 
user’s subjective predictions of the next two months’ MCCU earnings. The system will 
query the user to input the next two, three, or four months’ worth of MCCUs predicted by 
the user. The dialog component will read these inputs, check for validity, and project 
MCCU earnings a selected number of months beyond user predictions. At all menu levels, 
the option to exit the program will be available, as well as the option to return to previous 
menu screens where appropriate. 

The use of case statements found in programming languages such as 
PASCAL will enhance the maintainability of the system. Modules responsible for 
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displaying menu choices and reading user selection can be easily changed by adding to or 
deleting from menu selections. 

3. Modeling Component 

a . Description 

The modeling component of the Resource Management DSS architecture 
will be capable of giving the user a choice of modeling applications. For example, in the 
case of forecasting future monthly MCCU earnings, the user will be offered the opportu- 
nity to base the forecast on varying months of historic data or on varying months of user 
input predictions. Different lengths of future periods to be forecast will also be presented 
to the user. 

The overall goal of the modeling component is to not force the user into a 
specific modeling construct. The user should be offered the opportunity to choose from 
several different types of models that best suit user needs. There is no sense in requiring 
the user to predict the next six months worth of productivity if only one month in the future 
is required. The priority will be getting the most accurate data analysis possible from the 
model base. 

b. Construction 

The construction of the modeling component will be such that a single 
model is represented by a module in the structure chart. This method will facilitate the use 
of different models for desired applications and allow changes to existing models or addi- 
tions of new ones. Future iterations should allow the user to identify the need to use a 
general type of model and allow a search of the model base for a specific application the 
user requires. A model base consisting of many useful models will enhance the usability of 
the system. The Resource Management DSS will possess the characteristics of a tailor- 
made system, aiding users in finding and applying appropriate models. 
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D. SUMMARY 



The main thrust of this chapter was to take a portion of the Resource Management 
DSS from the analysis phase into the design phase. This chapter identified the first itera- 
tion of the system to be designed, transformed the analysis into design using structured and 
module specification methods, and described the architecture of the Resource Management 
DSS. 

The structured specification describes the logical design of the system using the data 
flow diagram (DFD). The DFD presents a graphic description of the overall system, taking 
the view down through several layers. Mini-specs aid in further describing this graphic 
presentation. 

The module specification phase takes the documentation from the structured specifi- 
cation phase and further describes the developing Resource Management DSS. The mod- 
ule specification describes how the system was to perform desired functions using the 
structure chart and module specs. From these two by-products of the module specification, 
follow-on researchers will easily produce source code to implement the first iteration of the 
Resource Management DSS. 

The final section of this chapter discussed the actual construction of the three DSS 
architecture components which were described in Chapter n. Within the data component, 
the four databases required for the first iteration of the Resource Management DSS were 
described. The dialog component was designed to guide the user through the different lev- 
els of the system by using a menu dialog interaction between user and system. The last 
DSS architecture component, the modeling component, was designed to use separate mod- 
ules within the source code to perform desired modeling functions on extracted data. As 
the Resource Management DSS develops, a model base will allow the user to choose from 
a variety of models. 
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It must be emphasized the design presented in this chapter is for Version 0, the first 
of many iterations through which the Resource Management DSS must pass prior to 
becoming the ultimate system envisioned by both user and builder. Continuous interaction 
between user and builder will serve to enhance the effectiveness of the Resource Manage- 
ment DSS and, as a result, enhance the effectiveness of the quality of decisions made by 
upper-level managers at SBHACH. 
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V. SUMMARY OF RESEARCH AND 
RECOMMENDATIONS FOR FUTURE STUDY 



The thesis research presented in the previous chapters documented the development 
of the Resource Management Decision Support System (DSS) from inception to design. 
The need for a computer-based system to aid Silas B. Hays Army Community Hospital 
(SBHACH) resource managers was discussed, and methodologies for identifying critical 
information needs of decision makers were presented. Data was collected through struc- 
tured interviews and analyzed in order to derive the hospital’s Critical Success Factors 
(CSFs). Finally, proposed measures were discussed that would give decision makers the 
ability to analyze data necessary to satisfy identified CSFs and the first iteration of the 
Resource Management DSS was designed. 

A. SUMMARY OF RESEARCH 

This section of the thesis emphasizes the important factors discovered during the 
course of the thesis research. The areas briefly discussed are the methodology used to 
derive SBHACH CSFs, the design of the first iteration of the Resource Management DSS, 
the value of the thesis research, and the suggested implementation procedure_for the 
Resource Management DSS. 

1. Derivation of CSFs 

The methodology used to derive CSFs from SBHACH resource managers was 
the structured interview. Six upper-level managers were interviewed. The data collected 
during interviews was used to develop the individual managers’ CSFs. Summaries of the 
interviews are found in Appendix C. 
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The next step in determining the hospital’s CSFs was to move from a manager’s 
focus of CSFs to an organizational focus. As discussed by Bullen and Rockart, the indi- 
vidual CSFs are aggregated and from this compilation organizational CSFs are derived 
[Bullen 81]. Each manager’s CSFs were analyzed and a master list of prioritized CSFs for 
the hospital was derived. Once organizational CSFs were listed, proposed measures that a 
computer system should possess to satisfy CSFs were developed. Table 5-1 summarizes 
the four CSFs derived from the research and presents the proposed measures to satisfy 
these organizational CSFs for SBHACH. 

TABLE 5-1 

CRITICAL SUCCESS FACTORS AND PROPOSED MEASURES 



Critical Success Factors 

CSF 1 Maintain sufficient fiscal resources 
to meet the demands for inpatient 
and outpatient health-care services. 



Proposed Measures 

• Compare current clinic work unit levels 
to historic values. 

• Forecast future clinical productivity 
using historic data and user-projected 
values. 

• Forecast future hospital productivity 
using historic data and user-projected 
values. 

• Compare current MCCU data to 
historical data and projected goals. 

• Project future MCCU values based on 
current trends of MCCU earnings and 
user-projected values. 

• Calculate unused capacity in the form of 
bed space and potential discharge 
information. 

• Calculate projected bed space required 
based on current trends. 
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TABLE 5- 1 (Continued) 

CRITICAL SUCCESS FACTORS AND PROPOSED MEASURES 



Critical Success Factors 

CSF 2 Maintain sufficient military and 
civilian personnel to adequately 
provide health-care services to 
fluctuating inpatient and outpatient 
levels. 



CSF 3 Monitor the impact of the Primary 
Care to Uniformed Services (PRI- 
MUS) clinics and the Civilian 
Health And Medical Program of 
the Uniformed Services (CHAM- 
PUS) reform initiative. 



CSF 4 Maintain a sufficient amount of 
medical equipment, in proper 
working order, to provide neces- 
sary health-care services to inpa- 
tient and outpatient demands. 



Proposed Measures 

• Project gains/losses for six months in 
the future for military and civilian 
personnel. 

• Forecast clinical staffing levels from 
historical data and user-projected input. 

• Compare different clinical productivity 
levels at the same time. 

• Measure the daily fluctuation of clinic 
productivity in work units compared to 
historical values. 

• Forecast the number of outpatients in 
the future based on historical referrals 
from the PRIMUS clinics. 

• Measure the daily fluctuation of clinic 
MCCUs earned compared to historical 
values. 

• Project trends of outpatient drops due to 
loss of outpatients to PRIMUS. 

• Forecast future monthly budget expen- 
ditures on capital equipment based on 
historical data. 

• Forecast future monthly budget expen- 
ditures on capital equipment based on 
projected user input. 



2. Design of First Iteration 

The methodologies used to design the first iteration of the Resource Manage- 
ment DSS were the structured specification and the module specification. Figure 5-1 illus- 
trates the use of these two methodologies producing documentation from which further 
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Figure 5-1. Transitions From Systems Analysis to Systems Design 



design is conducted, stopping short of source code development. The proposed measures 
developed from the CSFs are analyzed and the data flow diagram, mini-specs, and data 
dictionary are developed from the structured specification. 

Further design is conducted by using output of the structured specification 
phase as input to the module specification .phase. Finally, the structure chart and module 
specifications are developed. From these five outputs of structured design, the Resource 
Management DSS for SBHACH may be implemented. The documentation found in 
Appendices E, F, G, H, and I is used to describe the Resource Management DSS in terms 
of the data, dialog, and modeling components found in Figure 5-2. The databases for the 
Resource Management DSS are identified in the data component, and the different dialog 
styles and models used are listed in the dialog and modeling components. 

During the structured design phase, four databases were identified that will need 
to be established in order to support the Resource Management DSS. Data extracted from 
various reports and MIS (see Figure 5-2) will be put into these four databases. The two 
MCCU databases will supply data to graphically illustrate recent and historic MCCU earn- 
ing trends. The clinic and hospital monthly productivity databases will be used to analyze 
both individual clinic and hospital productivity values over varying time periods. 
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Figure 5-2. Resource Management DSS Components 



The dialog component for the Resource Management DSS will provide the 
capability of guiding the user through various levels of menus in order to view required 
data. The menu-driven dialog was chosen as the method of communication between user 
and system due to the ease of interaction and, more importantly, because this specific 
method supports novice computer users and infrequent users alike. Making the dialog 
component simple to use stresses flexibility in allowing various managers to use the 
Resource Management DSS and accommodates the frequent job changes found in most 
military environments. 

The most important aspect of the modeling component was the development of 
a model base type of management system. As the Resource Management DSS is imple- 
mented, different models will be added to the system and existing ones will be modified. 
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The modeling component of the Resource Management DSS is built to incorporate a single 
model within a module of source code. This flexibility will allow system maintainers to 
make modeling changes easily. 

3. Value of Research 

The research conducted will primarily aid upper-level managers at SBHACH. 
Once implemented, the Resource Management DSS will provide resource managers the 
ability to analyze relevant data for ill-structured decision problems commonly found in the 
hospital administration field and manipulate this data in different manners. The overall 
value of the research will ultimately be the improved decision-making quality the Resource 
Management DSS will lend to upper-level managers at SBHACH. The design of the 
Resource Management DSS proposes timely access to relevant data that was not available 
prior to this research. The added capability of manipulating data in various ways will allow 
the system users to make ad hoc queries into different databases and ask “What if?” ques- 
tions when required. 

4. Implementation Procedures 

The logical next step of developing the Resource Management DSS is to imple- 
ment the system by writing source code and to deliver the system to the users for review. 
The system documentation developed in the design phase should be sufficient for the easy 
development of source code. The decision must be made as to which programming lan- 
guage will be used. It is possible the first iteration could be developed in more than one 
programming language and results compared. 

Once the first iteration is implemented, the delivered product should be delivered 
to the user for review. After getting user feedback, the first iteration could be built on to 
include user changes and proposed measures to satisfy more of the first CSF as well as 
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other CSFs. This iterative process will foster the evolution of a DSS that truly reflects 
SBHACH user requirements. 

B. OPPORTUNITIES FOR FUTURE RESEARCH 

The research presented in the thesis represents the first of several iterations that will 
be conducted before the Resource Management DSS evolves into a fully functioning Deci- 
sion Support System. During the course of research, some areas were identified that may 
lead to future research; automating the data extraction task and defining the tasks of the 
database administrator are two examples. 

1. Data Extraction 

There is no automated data extraction method that extracts data from the various 
sources in the hospital. The different MIS at the hospital provide data as well as the previ- 
ously identified reports (see Figure 5-2). Further research in this area could identify which 
data sources provide the most accurate data and discover methods of extracting data auto- 
matically from the various MIS in use at the hospital. Adding modules to the commercial 
MIS was ruled out due to violating commercial contracts with system maintainers. Detailed 
studies might identify methods of extracting the data from the different MIS without vio- 
lating these commercial contracts. 

2. Establishing Duties of Database Administrator 

The intention of the hospital is to implement a local area network with terminals 
provided to key resource managers within the hospital. The Resource Management DSS is 
one of several software packages that will be used on the network (electronic mail would 
also be included). Further research could identify the duties and operating procedures of 
the assigned database administrator of the local area network. This research would be 
instrumental in establishing and maintaining the many databases that will be created by 
future iterations of the Resource Management DSS. 



83 



APPENDIX A 



INITIAL FACT-FINDING INTERVIEW 
A. DESCRIPTION 

This appendix summarizes the initial interview conducted on 1 March, 1988, by the 
author to discuss information management problems at Silas B. Hays Army Community 
Hospital (SBHACH). Attendees were the Chief of Resource Management Division and the 
Chief of Clinical Support Division. Names of the resource managers holding these billets 
have been omitted though nothing inappropriate was discussed. 

An important point the interview brought out was the current method the Department 
of Defense (DOD) uses to reimburse health-care services provided by SBHACH. The 
current system. Medical Care Composite Units (MCCUs), was described as archaic and 
difficult to use by resource managers. The major problem of the MCCU method is that it 
does not provide a breakdown by operational department that may be used by managers as 
a monitoring tool. The feedback from DOD is a lump sum by quarter of what each Medical 
Treatment Facility (MTF) has earned. 

The ideal system the interviewees described would separate “winners” from “losers” 
in terms of outputs to inputs. Managers want the ability to analyze each operational 
department and determine if the outputs in the form of health-care services rendered are 
equal to the number of MCCUs earned. They also summarized in the interview the other 
areas of information management they wanted the proposed system to provide. 
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B . SUMMARY OF INTERVIEW 



The purpose of the meeting was to identify what requirements upper-level 
management (Hospital Commander and Executive Officer) wanted from existing 
information systems and what could be done to solve information needs. 

They noted that due to budget constraints, managers at SBHACH were essentially 
forced to make use of existing Management Information Systems (MIS), i.e., no funding 
was available for a new MIS. Given this, they want the development of some method for 
identifying “winners” and “losers” in terms of the operational medical departments in the 
MTF. He explained that Medical Care Composite Units (MCCUs) are how the DOD 
allocates budget funding to Medical Treatment Facilities (MTFs). They next described in 
detail the current method the MCCU system used to earn DOD reimbursement for 
SBHACH. When health-care providers (doctors, nurses, lab technicians...) provide 
services to patients in the form of consults, surgery, pharmaceutical prescriptions, bed 
space, x-rays, and other varied services, the hospital is credited with MCCUs depending 
on the type of service. For example, an outpatient visit is worth 0.3 MCCUs, a live birth is 
valued at 10 MCCUs, and an admission is worth 10 MCCUs the first day and 1 MCCU 
every day thereafter. 

Data that determines the number of MCCUs provided is maintained daily on an 
information system called the Uniform Chart of Accounts Performance Expense Reports 
System (UCAPERS). This data is input by type and cost of service provided. The 
information is updated daily, and monthly a tape summarizing all health-care services 
provided is sent to a DOD run facility that calculates the data into MCCUs. This data, in 
the form of MCCUs, is then used by DOD personnel to provide monetary funding to 
SBHACH in reimbursement for health-care services provided at the hospital. A hard-copy 
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report comes back to the hospital summarizing the previous quarter by the amount of 
MCCUs the entire MTF earned. 

They acknowledged the MCCU method is archaic. The financial benefits are in direct 
conflict to modem medical treatment practices; for example, the hospital will get more 
“points” for admitting a patient than for treating him/her as an outpatient 

They next pointed out that the information they want is supplied in part on two of the 
MIS in the hospital, UCAPERS and the Automated Quality of Care Evaluation Support 
System (AQCESS). 

“Winners” are those departments that provide health-care services which earn an 
MCCU value equal or greater than services expended. “Losers” are those health-care 
services which are provided and either do not earn an equal amount of MCCUs or are not 
reimbursable. They noted that generally an admission into the hospital and a stay of over 
four days represented a loss of MCCUs to the hospital after the fourth day. The problem 
for resource managers is they cannot dictate that medical services above a certain threshold 
will not be performed. The specialists would lose their expertise and, more importantly, 
there would be tremendous social ramifications in denying medical services. They pointed 
out that even though hospital managers have a general idea of the financial position the 
hospital is in, the feedback from the MCCU method is not timely (quarterly basis) and may 
conflict with management estimates. 

The system they envision would provide reports at least on a quarterly basis and 
would provide the following information: 

• Identify by department and/or physician the workload performed; 

• Show which health-care services performed are reimbursed in terms of MCCUs; 

• Show which services are not reimbursed; 

• Use outputs to monitor progress of departments which are financial sinks; 
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• Use outputs to recognize departments which are performing well. 

The last part of the meeting was spent identifying specific data that should be 
incorporated into the DSS. Table A-l summarizes the type of measurements upper-level 
management was looking for. 



TABLE A-l 

QUANTITATIVE MEASURES REQUESTED 
BY UPPER-LEVEL MANAGERS 



Inpatient Revenue/patient day 
Number of admissions 
Length of stay 

Mean hospital salary for community 
Hours worked by department 
Number of unfilled positions 
Absentee rate 



Outpatient revenue/visit 
Census (number of beds) 

Mean hospital salary 
Wage expenses by department 
Supply expenses by department 
Turnover rate 

Nursing work hours/patient day 



In addition to the requirements in Table A-l, they also mentioned that it would be 
convenient to have a measurement of the average clinic waiting time for a patient, loss of 
workload due to unused health-care provider capacity, and the number of unused 
appointments. 
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APPENDIX B 



STRUCTURED INTERVIEW FORM 

I. DESCRIPTION 

This appendix contains structured questions for the conduct of interviews at Silas B. 
Hays Army Community Hospital (SBHACH). Questions were developed to determine 
management Critical Success Factors (CSFs) [Bullen 81, Rockart 79, Rockart 82, and 
Rockart and Treacy 82]. 

II. QUESTIONS USED IN INTERVIEWS 

A. Industry 

1 . In what areas will a failure hurt you the most in your job? 

B . Competitive Strategy and Industry Position 

1 . How do you view your job and the organization as a whole? Do you 
function as a caretaker or strategic planner? 

2. What are your formal and informal operational goals over the next 12 
months? 

3 . What information do you need to maintain Silas B. Hays in the position of a 
competent provider of health-care services? Do community factors affect 
you? If yes, how much are you affected by the community? 

C . Environmental Factors 

1 . What information is necessary for managing resources in the health-care 
industry? 

2 . What budget constraints do you face in your job? 

3 . Are there certain health-care services that are not economical to fund? 

4 . How do changes in patient levels affect your job? 
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D. Temporal Factors 

1 . What current problems demand your attention now? 

2. What latest crises are you addressing presently? 

E. Managerial Position 

1 . What is your role in the overall organization? 

2 . What information do you need to perform your job? 

3 . Where do you get this information from? 

4. What kinds of information are you asked to calculate, process, and present 
the most? 

5 . Is the data readily available in the form you need or does it need to be pro- 
cessed? If yes, how much processing is necessary? 

6 . Do you require mostly current data or historical data in your job? 

7 . What techniques do you use to solve the biggest problems confronting you? 
Where do you go to find the information necessary to do this? 

8 . Do you get information you need fast enough? 

F . Internal and External Factors 

1 . What areas affect your job the most that you are unable to control? 

2. In the areas that you can control, what items do you find a need to control 
the most? 

G . Monitoring and Building Factors 

1 . What best describes your job? Is it a function of monitoring by reporting 
findings to seniors or do you do more planning by looking at trends and 
forecasting future developments and requirements? 

2. What are the most important things to find out when you come back from an 
extended leave or TDY period? 

3 . What methods do you use to measure success or failure? 
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4. What kind of soft data do you like to know? Do you rely on word of 
mouth, rumors, personal observations of staff, or other soft inputs? 
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APPENDIX C 



SUMMARY OF CRITICAL SUCCESS FACTOR INTERVIEWS 

A. DESCRIPTION 

This appendix summarizes the six interviews conducted with senior resource man- 
agers at Silas B. Hays Army Community Hospital (SBHACH). These interviews were 
used to develop organizational critical success factors. A separate interview summary is 
provided for each resource manager interviewed. The interviews are presented in the order 
in which they were conducted. Names of the resource managers holding the billets have 
been omitted though there is nothing inappropriate in any of the interviews. 

B . SUMMARY OF INTERVIEW WITH THE NURSING METHODS 

ANALYST 

The Nursing Methods Analyst works in the Resource Management Division. The job 
she is performing is a follow-on tour after receiving a Master of Science in Nursing 
Administration. 

1. Industry Factors 

The Nursing Methods Analyst pointed out that SBHACH does not have a char- 
ter narrowly defining goals and objectives, so it was difficult for her to define industry 
factors that affect her job. This motivated her to explain that the hospital is responsible for 
satisfying those general health-care requirements that active duty, dependent, and retiree 
personnel need. Proper health care to this population in the surrounding community was 
first and foremost in the hospital’s objectives. 
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2. Competitive Strategy and Industry Position: 



She described the overall strategy of SBHACH as providing support to 
inpatients over outpatients and the staffing of the workcenters that provide direct patient 
support over those that provide administrative support. 

3. Environmental Factors 

There are certain factors in her job over which she has no control. She depends 
on reports from which she extracts data from to generate her own reports. This aspect of 
her job was considered frustrating because she could not control the timing, accuracy, or 
flow of this information. 

She went on to point out that the Hospital Commander required the hospital to 
provide certain types of health-care services that are losing propositions. For example, the 
neurology clinic does not see enough patients to justify its presence in the hospital, yet the 
Hospital Commander has decided to continue this support in order to satisfy sporadic 
community needs. Closing this clinic and similar nonproductive clinics would have a neg- 
ative impact on the reputation of the hospital. 

Another important source of outside influence comes from the Health Services 
Command (HSC). For example, HSC has dictated to all Medical Treatment Facilities 
(MTFs) that they provide two areas of support in AIDS testing. Fenced budget allocations 
are provided to test active duty personnel at Fort Ord for exposure to the AIDS virus. This 
includes documenting the results and providing counseling and follow-on medical services 
for active duty members exposed to the virus. The second initiative in the AIDS arena is to 
require testing of all active duty inpatients and to strongly suggest testing for dependent and 
retiree inpatients. The purpose is to identify any inpatients who may cany the AIDS virus 
so health-care providers can take appropriate preventive measures while working with body 
fluids. 
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4. Temporal Factors 



She discussed two temporal factors affecting her job: the implementation of the 
Automated Quality of Care Evaluation Support System (AQCESS) and getting a reporting 
system accepted that she has developed to report on clinic productivity. 

The AQCESS system used to require an inordinate amount of her time moni- 
toring the progress of implementation and transition to users at the hospital clinics. This 
system, developed by contractors, gave individual clinics appointment scheduling capabil- 
ity to ease the burden on the crowded centralized scheduling system. The “bugs” are 
slowly being worked out of the system and, as time passes, it requires less of her time. 

The factor on which she spends the majority of her time is a productivity report 
she is attempting to get accepted as a monitoring tool. The developed report satisfies the 
major information needs in her job — how to measure output of individual clinics for better 
civilian and military personnel staffing. 

She described the mechanics of extracting the data from other reports and 
databases in order to generate her final product, which is presented to the Chief of 
Resource Management Division. On a monthly basis, clinics hand-prepare a 310 Report 
which identifies by health-care provider the number of total work units he/she has earned 
the past month. The monthly work unit average is then calculated for the clinic. It is 
important to note that a work unit depends on the type of health-care service being 
rendered — it may be x-rays taken, patients seen, pharmaceuticals dispensed, or some other 
dictated method from HSC. The 310 Report is then forwarded to the Resource Manage- 
ment Division. 

She further explained that administrative personnel in her division enter this 
work-center data into a database going back two years. This database contains a summary 
of the 310 Report in the form of a Running Schedule X Report. The Running Schedule X 
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Report maintains by clinic a monthly running total of work units earned, staffing strength, 
and work units earned by personnel not part of the paid staff (volunteers, Red Cross per- 
sonnel, etc.). 

She explained she next extracts data from both reports to make her Productivity 
Report. Her report takes average work units earned by each clinic for the month and the 
average staffing of clinics excluding non-payroll volunteer work, and compares these two 
factors with the number of staff HSC has determined will be assigned to the clinic. The 
final product is input to a Lotus 1-2-3 software package that summarizes, by month, aver- 
age staffing levels and work units performed. This information is used primarily as a 
monitoring tool that compares clinic output with staffing levels. With this information, 
resource managers can look at a particular clinic over a period of several months and verify 
that with additional staffing a clinic has provided more work units, as would be expected. 
This tool can also identify negative trends, such as additions to staffing and no significant 
increase in work units provided or even a reverse output trend. 

Ultimately, this report is used to directly affect civilian hiring and reallocation of 
military personnel. Often she is asked to analyze the impact of reducing clinic staffing lev- 
els. She sees this Productivity Report as an essential tool in performing her job. 

5. Managerial Position 

She views her job as a staff officer, providing input to the Chief of Resource 
Management Division on any aspect of the hospital that is required. She is called upon to 
perform any catch-all job that does not fall within other job descriptions and deals with 
resource management monitoring. Her job deals with administrative issues affecting nurs- 
ing, patient care, and patient complaints. An example she pointed out would be the 
investigation of whether a new inpatient ward or clinic should be opened. She would 
assess the impact this venture would have on overall goals and objectives of the hospital. 
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As described earlier, she needs data from a varied number of Management 
Information Systems (MIS) currently in operation. She works predominantly with histori- 
cal data and some current data to project workload trends in the future. The data she does 
use requires a great deal of processing by her staff into a form that is usable for presenta- 
tion to decision makers. 

6. Internal and External Factors 

The only factor she wished she could control is the method HSC uses to dictate 
the amount of staff to be assigned to a clinic. She explained that in a few clinics, the num- 
ber of health-care providers authorized is based on an uncontrollable factor such as the 
civilian population in the surrounding geographical area. This arbitrary authorization of 
staff to a clinic sometimes frustrates resource managers when they attempt to reallocate 
health-care providers in contrast to HSC guidance. 

7. Monitoring and Building Factors 

She predominantly is concerned with monitoring output from clinic and ward 
staffing levels and reporting trends to the Chief of Resource Management Division. She 
explained this area of her job is most important for her success or failure in the Resource 
Management Division. From the information provided through her Productivity Report, 
the Chief of Resource Management Division can make educated decisions concerning 
staffing levels throughout the hospital. 

C. SUMMARY OF INTERVIEW WITH THE CHIEF OF PATIENT 

ADMINISTRATION DIVISION 

The Chief of Patient Administration Division works directly for the Deputy 
Commander for Administration. He took over the job only four months ago. 
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1. Industry Factors 

He could identify one factor about which he is most concerned within the 
Patient Administration Division. His work center is responsible for all inpatient records 
and birth and death information. The accuracy and confidentiality of this data is vitally 
important to his job success. He therefore staffs his work centers accordingly. He assigns 
quality personnel to the record-keeping work centers over the more mundane ones such as 
word processing. 

2. Competitive Strategy and Industry Position 

He viewed his job as more a caretaker than a strategic planner. He felt that a 
mismanaged Patient Administration Division can significantly slow a hospital’s internal 
functioning as well as destroy its credibility with erroneously reported births and deaths. 
For this reason, an officer capable of dealing with all aspects of administrative reporting is 
required to closely supervise accurate administrative documentation. 

He pointed out that one of his informal goals in the next 12 months was to get 
his workcenter’s staffing level back to a level he feels comfortable with. At this time, he 
has several vacant positions in the medical records section, and if these positions are not 
filled quickly it may affect the accuracy and confidentiality issue. 

3. Environmental Factors 

He explained that fluctuating patient levels had the most significant impact on 
his job. When patient levels increase dramatically, his staff is flooded with Civilian Health 
And Medical Program of the Uniformed Services (CHAMPUS) requests and associated 
paperwork. SBHACH has approximately 125 beds for inpatients. When this space 
approaches full capacity, his staff has difficulty in keeping up with the administrative 
paperwork such as surgery narratives, check-in/check-out functions, birth/death certifi- 
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cates, and workload summaries for all work centers. He stated, “If the hospital closed 
down today, we would finally finish our job about two weeks later.” 

4. Temporal Factors 

He identified two temporal factors affecting him now: the two Primary Care to 
Uniformed Services (PRIMUS) clinics being opened at The Presidio of Monterey and 
Salinas, California, and the CHAMPUS Reform Initiative. 

With the opening of the two satellite PRIMUS clinics, his staff will provide 
administrative support by maintaining health records initiated by the civilian funded pro- 
grams. When patients are treated at these satellite locations, his staff will provide periodic 
audit services and correct administrative defects discovered. 

The CHAMPUS Reform Initiative is a program sponsored by the HSC to retard 
the yearly costs of CHAMPUS, which currently are rising at a rate of 25 percent a year. In 
effect, the purpose of the CHAMPUS reform initiative is to identify a number of health- 
care providers outside the military hospital system who can provide medical care for the 
overflow of patients at SBHACH. Using these health-care providers under contract will 
cost the government less in CHAMPUS costs than the current method of using outside 
medical practitioners. He will be required to provide administrative support to the team that 
will be setting up the new CHAMPUS system in the surrounding community. 

5. Managerial Position 

He does very little information management in the hospital. He identified his 
work center as a source of one feeder report which resource managers use. The monthly 
Workload Report is a summary of data obtained from the AQCESS MIS and provides a 
breakout by clinic and health-care provider of the workload accomplished over a given 
period of time. This report functions as a monthly database and is forwarded to the 
Resource Management Division, where data is extracted to generate a number of reports to 
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monitor clinic productivity. A spin-off of this report calculates the number of Medical Care 
Composite Units (MCCUs) the hospital has unofficially earned for resource allocation. 
The MCCU estimation is used by administrators to monitor the individual clinics. 

6. Internal and External Factors 

He reiterated that he is affected externally by the patient levels and cannot react 
to this fluctuation easily. 

7. Monitoring and Building Factors 

He monitors his staffing levels very closely. He noted that if certain key posi- 
tions remain vacant for extended periods, he will assume the job is not being done as effi- 
ciently as possible and takes appropriate quality assurance action to inspect output and 
make necessary corrections. 

D. SUMMARY OF INTERVIEW WITH THE CHIEF OF PERSONNEL 

DIVISION 

The Chief of Personnel Division works directly for the Deputy Commander of 
Administration. He has been in the current job for over a year and moved up from other 
assorted administrative jobs in the hospital. 

1. Industry Factors 

He identified one major health-care industry factor that affected his division. 
He pointed out that the hiring of civilian personnel was always at the forefront of his atten- 
tion. The Department of Defense (DOD) hiring freeze especially affects the hospital in the 
large number of vacant positions. 

2. Competitive Strategy and Industry Position 

He viewed his job as 90 percent caretaker and the remainder as a strategic plan- 
ner. He described his job as maintaining personnel records support for all military and 
civilian personnel working within the hospital. 
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The military personnel have their records maintained on a local MIS called 
Standard Installation Divisional Personnel System (SIDPERS), which feeds the Fort Ord 
SIDPERS database. The information is kept on over 15 fields of data elements, including 
rank, social security number, name, date of birth, and other miscellaneous personal infor- 
mation that would be kept by administrative and record-keeping personnel. 

His people are responsible for maintaining the accuracy of these records, mak- 
ing changes as personal information changes for assigned personnel, and adding new 
arrivals and deleting transfers. Some data fields are protected, such as the grade and pay 
fields. All other fields may be updated and updates are then sent to the database on post. 
Any pay upgrades are hand-routed to the database on post and the changes are reflected in a 
short time. 

He uses this database to view the information in different ways to answer 
queries that come up during the course of business. A sample question might be “How 
many enlisted troops are working at the hospital who have a rank over E-5 and are single?” 
Although SIDPERS provides an ad hoc query function that allows users to view the 
database, it is limited in scope. He noted that questions arise that are answered by 
manually combining both SIDPERS and other databases and hand-sorting personnel 
records. In these cases, a method of viewing this data in some relational format would 
greatly enhance the Personnel Division. He noted that the amount of time spent on access- 
ing the database was 70 percent ad hoc and 30 percent for routine queries. 

One of the short-term goals on which he is working is the maintenance of mili- 
tary health-care providers’ qualification records for going into combat with the rapid 
deployable forces. Health-care providers (corpsmen, doctors, and nurses) are assigned to 
deployable units and qualifications must be met in order for them to go into combat with the 
ground units when they deploy. The qualifications record-keeping is a major task for him 
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and his staff. Some of the data fields are maintained by SIDPERS and some are maintained 
manually. He would like to implement some system that could use SIDPERS data ele- 
ments along with others in a relational database. It is vitally important for health-care 
providers to have up-to-date qualifications in order to go into potential combat situations. 
The system he envisions would automatically flag personnel whose qualifications have 
expired or will expire prior to the next scheduled training cycle. 

An important part of his job is maintaining staff levels of both military and 
civilian personnel. The hospital is authorized only so many military health-care providers, 
and the remaining positions are filled by civilian employees. In the event of budget cuts, it 
is necessary to reduce the number of civilians and/or freeze the hiring rate. When this hap- 
pens, the remaining military must work longer shifts and military personnel assigned 
directly to ground units must be pulled back to the hospital to augment the staff until relief 
in the form of reduced workload or civilian hires is accomplished. As shortages exist 
within the hospital in civilian employees, a committee consisting of managers meets as 
needed to decide on the hiring for departments that are understaffed A critical information 
requirement is some sort of quantitative tool to determine which departments are in the 
greatest need for new employees. 

3. Temporal Factors 

The only temporal problem he sees at this time is the budget situation. The state 
of the budget has caused a hiring freeze on civilian employees. At this time, military per- 
sonnel have been jockeyed around and shift hours have been expanded to handle this crisis. 
There is not much anyone at the hospital can do to alleviate this, but they can ensure that 
military health-care providers moved within the hospital or added from the outside as aug- 
mentees are done so in an intelligent manner. In other words, clinics and wards that need 
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people most get these people, and the impact of reassigning an individual within the hospi- 
tal is investigated fully. 

4. Managerial Position 

He functions as a staff officer who maintains up-to-date information on military 
and civilian personnel. He accesses two MIS to maintain records on the hospital work 
force. On the military side, he is the troop commander responsible for maintaining good 
order and discipline as well as promotions. For the civilian workforce, he is responsible 
for recruiting and hiring when the need arises. The Uniform Chart of Accounts Perfor- 
mance Expense Reports System (UCAPERS) provides information on civilian health-care 
providers, and the SIDPERS system maintains files on military personnel. 

If the military work force is experiencing a shortage, he is required to deal with 
the next level of command to get new personnel assigned to SBHACH. If it is the civilian 
work force that is short, the committee decides on what job description is required and he is 
responsible for advertising and hiring. 

5. Internal and External Factors 

The dominant factor in his job is to ensure that the work force is maintained at 
the level necessary to provide competent health care to patients. Even if this goal is to be 
performed at the expense of administrative functions, it must be done. Since his division is 
primarily administrative in nature, he is prepared to sacrifice human resources for the more 
important clinics. 

6. Monitoring and Building Factors 

In order to answer questions concerning staffing levels and hiring rates, he 
must do a great deal of ad hoc questioning of his staff. The information he requires is not 
always readily available and requires him to search out the necessary data to make 
decisions. 
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He always monitors the unit discipline and reassignment of personnel within the 
hospital. He needs to continuously know any changes to staffing levels in order to keep 
the commander apprised of changes that will affect patient treatment. 

E. SUMMARY OF INTERVIEW WITH THE DEPUTY COMMANDER FOR 

ADMINISTRATION 

The Deputy Commander for Administration at SBHACH is responsible for all ad- 
ministrative matters within the hospital and reports directly to the Hospital Commander. 
Prior to taking this post at Fort Ord, he served in a smaller hospital overseas, where he 
performed a similar job. 

1. Industry Factors 

The information area he feels the hospital needs the most is timely, accurate 
information. He requires information on earned MCCUs and compares this figure to out- 
put spent by the individual clinics and wards. Areas that get the hospital in trouble are 
spending more on output then is earned through health-care services provided and the slow 
method of calculating MCCUs earned by the hospital. 

2. Competitive Strategy and Industry Position 

He described his job as being both a monitor and strategic planner, but more 
towards monitoring tasks. He functions as a staff officer to the Hospital Commander and 
provides the commander with information on administrative functions. 

He identified two primary goals he is attempting to accomplish within the next 
12 months. He is trying to market the nursing positions at the hospital and increase the 
productivity of the individual departments through education and training. 

There is a civilian nursing shortage at SBHACH. The hospital is authorized to 
pay civilian nurses at a given rate, but the surrounding community is paying their nursing 
staff at a much higher rate. Therefore, it is difficult to attract nurses to SBHACH. The 
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method he is using to solve this problem is to increase the productivity of the hospital, earn 
more funding for the hospital through this increased productivity, and take the funding and 
augment salaries of the civilian nursing staff in order to attract and maintain needed nurses. 
Normally, excess funds would be turned into HSC for reallocation. However, he has 
struck a deal that allows him to use these funds for civilian nursing and some capital 
equipment 

3. Environmental Factors 

He is concerned with the effect the two PRIMUS clinics that are being opened 
near Fort Ord will have on the hospital. The PRIMUS clinics were designed to provide 
health care to active duty, retired, and dependent personnel as an alternative to the medical 
treatment also provided at SBHACH. The medical care is provided by mostly civilian per- 
sonnel under contract and covers small injuries, common illnesses, and general medical 
problems. Although the two PRIMUS clinics will duplicate a percentage of medical care 
that is already provided at SBHACH, there are certain medical services not provided. 
SBHACH will still offer all medical services, but the PRIMUS clinics will take some of the 
workload from the hospital and give additional medical care to the surrounding military 
community. The PRIMUS clinics can have three effects on the hospital: They may attract 
patients away from the hospital and cause the overall hospital productivity to drop, they 
may increase the amount of patients treated through patient referrals, or the patient levels 
may remain the same. 

Another identified environmental factor that affects the hospital is the lack of 
control over military construction. Military construction is provided locally from the base 
and the hospital has little control over it from the standpoint of pushing projects through to 
completion that they deem as the most important. He cannot contract out specific projects 
to be completed and must rely on the post to provide this support. 
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4. Temporal Factors 

He identified a number of temporal factors with which he is dealing at 
SBHACH. The most important factors are how the PRIMUS clinics and the CHAMPUS 
reform initiative in combination will affect the workload at the hospital. Hospital adminis- 
trators are waiting to see how the workload will fluctuate before taking action to address 
these factors. An action officer has been assigned to monitor this factor. 

5. Managerial Position 

He described his managerial position as one of evaluating performance. He 
constantly monitors the levels of clinic productivity, patient levels, and consumption of 
resources in treating patients. He gets most of the information he needs from the Produc- 
tivity Report supplied by the Resource Management Division that identifies a variety of 
information, including the capacity of each ward and the status of the nursing staff. 

He relies heavily on the earned value of MCCUs throughout the hospital. He 
needs to know the current earned value of the hospital’s MCCUs in relation to the estab- 
lished goal set by his office. Unfortunately, the exact number of MCCUs earned to date is 
accurate to only ten days prior to the present date. If he wants the exact number of MCCUs 
earned to date, it takes about ten days to compile this figure for use. 

6. Internal and External Factors 

One of the areas that affects his job most that he is unable to control is the cyclic 
nursing problem. As nursing levels drop due to fewer nurses hired at the hospital, patient 
levels drop because there are not enough nurses available to staff hospital wards, and as a 
result the hospital’s productivity declines. Higher headquarters sees this decline in 
productivity, determines that the hospital has excess capacity, lowers the amount of nurses 
allowed to be hired, and the cycle then repeats. 
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7. Monitoring and Building Factors 

He stated that his job is primarily a job of monitoring the input, output, and 
budget expenditures of the hospital. He is concerned with significant budget decisions and 
patient levels. He uses the MCCU method as a monitoring tool to measure the success of a 
specific ward within the hospital. The goal for the hospital is to earn 780 MCCUs per day 
and spend $24 worth of resources on each MCCU earned. Currently, the hospital is earn- 
ing 840 MCCUs per day, and spending $18 worth of resources for each MCCU earned. 

The profit the hospital is generating is used to provide salary incentives to attract 
and maintain an appropriate nursing staff level within the hospital as well as to purchase 
equipment that is at the forefront of certain medical technologies to provide the latest health- 
care possible. 

He maintains a monthly statistic report that follows each clinic and provides a 
breakdown of current monthly admissions, average daily admissions, and an optimal 
admission goal established for each clinic based on spending $20 on resources per MCCU. 
With this report, he can easily see which clinics are ahead or behind their optimal goals and 
take corrective action. Unfortunately, this report is only a snapshot at one particular time 
during the month and the information becomes dated quickly. There is a need for a report 
that is on-line and provides this same information in order to make educated decisions. 

F. SUMMARY OF INTERVIEW WITH THE DEPUTY COMMANDER FOR 
CLINICAL SERVICES 

The Deputy Commander for Clinical Services reports directly to the Hospital Com- 
mander on the operational function and performance of the clinics and wards. 

1. Industry Factors 

He is most concerned with maintaining the working level of the hospital and 
staff up to the bed capacity to ensure full usage of medical treatment facilities. Maintaining 
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the inpatient levels at or near the hospital’s bed capacity ensures proper training of person- 
nel assigned in resident programs and provides the surrounding community with adequate 
health-care services. 

2. Competitive Strategy and Industry Position 

He functions as a caretaker to report on the status of the clinics and wards 
throughout the hospital. He is also responsible for maintaining proper staffing levels in the 
clinics and wards. Although personnel are trained in specific health-care areas such as 
orthopedics, nursing, pharmaceutical techniques, etc., he still has the ability to move per- 
sonnel around to the extent of filling gaps where needed and to provide proper training to 
health-care providers. 

3. Environmental Factors 

The only environmental factor he could point out was the nursing shortage that 
is affecting the hospital. This problem is well documented in previous interviews. 

4. Temporal Factors 

Also noted in previous interviews is the effect the PRIMUS clinics will have on 
the patient levels of the hospital. He described this factor as important because the 
PRIMUS clinics may take away business as well as refer patients in large amounts. 

5. Managerial Position 

He uses three reports to monitor the individual clinics within the hospital: the 
Nursing Report, the Officer of the Day Report, and the Administrative Officer of the Day 
Report. He stated that he found everything he needed in these reports to provide necessary 
direction to the wards and clinics. 

The Nursing Report provides information about inpatients in the form of identi- 
fying the most severe cases and those cases that may have a command interest. The report 
is broken down by ward and provides the number of patients in each ward, the capacity of 
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the ward, and certain traits such as patient categories, potential discharges, and age traits. 
This report spans the past 24-hour period. 

The Officer of the Day Report provides the number of admissions for a given 
24-hour period, serious illness and deaths, command interest cases, and training accident 
cases. This data is used to monitor the status on patients and provide feedback to health- 
care administrators on selected patients. 

The last report, The Administrative Officer of the Day Report, is used to pro- 
vide information on such items as food services and hospital security. These items are not 
as critical in nature as the Officer of the Day Report, yet necessary to monitor the hospital. 

6. Monitoring and Building Factors 

He primarily monitors the patient satisfaction throughout the hospital and the 
numbers of patients in the hospital. If patient satisfaction is not adequate in a certain clinic 
and there is a trend developing, he takes the action necessary to set the clinic back on the 
right track. 

G. SUMMARY OF INTERVIEW WITH THE COMMANDING OFFICER, 

SBHACH 

The Commanding Officer of SBHACH has filled this position for at least two years. 
Prior to this position, he served at SBHACH in other job billets, including the Deputy 
Commander for Clinical Services, before stepping up as the Commanding Officer of 
SBHACH. 

1. Industry Factors 

He explained that his job was no different than the civilian counterpart to his 
job. He requires fast, accurate information from all parts of the hospital about the entire 
organization. He depends on his staff to keep him informed on any important detail that 
may affect the reputation of the hospital. 
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Two other important industry factors on which he needs information are what is 
happening in the department of surgery and how much unused capacity in the form of 
unused bed space exists daily. Every morning he conducts a morning status meeting that 
provides him with information on what type of surgery will be performed for that day, how 
it went the previous day, and the unused bed space over the past 24-hour period. 

2. Competitive Strategy And Industry Position 

The Commanding Officer pointed out that his major goals in this area were 
monitoring funding constraints and preparing for anticipated needs. He talked about how 
the lack of funds this year has made it difficult for the hospital to hire needed civilian 
health-care providers, specifically nurses. This has caused him to approach the nursing 
issue in a unique manner. 

The resource managers at SBHACH have increased the productivity of the 
clinics in order to earn excess funds which can be spent on attracting civilian nurses at an 
increased pay rate than what they are authorized to pay now. The pay rate for civilian 
nurses at SBHACH is much lower than the surrounding community and it is difficult to 
attract good nurses to the hospital. By saving this money through increased productivity, 
they can now establish a salary to compete with the outside community. 

He went on to point out that the hospital plans for anticipated needs due to 
changes in technology. They must be able to procure the necessary personnel and machin- 
ery to keep the hospital in the position of a competent provider of health-care services on 
the leading edge of recent medical advances. 

3. Environmental Factors 

He presented three environmental factors that affect the hospital: the budgetary 
constraints requiring the hospital to operate at a profit, fluctuating patient levels, and 
changes in training intensity levels at Fort Ord. 
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Budgetary constraints require SBHACH to operate at a profit. The hospital 
must provide adequate health-care services and yet not overspend its earned allotment of 
funds. As Chapter III describes, the method of reimbursement for health-care services 
provided is the Medical Care Composite Unit (MCCU). He requires an accurate approxi- 
mation of what the hospital’s current spending level is in order to make decisions on pur- 
chasing capital equipment and hiring civilian employees. Unfortunately, the method for 
reporting this information is slow, taking up to ten days at a time to provide managers with 
an accurate estimate of MCCUs earned to date. 

The Hospital Commander explained that fluctuating patient levels affected the 
hospital in terms of earning MCCUs. Simply put, if patient levels drop significantly, he 
can expect a corresponding drop in the MCCU rate earned as well. If this level persists, he 
must investigate to find out why this is happening and take appropriate action if possible. 

The last environmental factor presented was the effect changing levels of train- 
ing intensity at Fort Ord had on the hospital. As training by ground units intensifies, the 
injury rate of personnel involved increases. A majority of these injuries are orthopedic in 
nature and require the services of skilled orthopedic personnel. To augment his orthopedic 
clinic, he has thought about implementing a sports physician to handle those injuries that 
are frequently seen from training requirements. 

4. Temporal Factors 

He pointed out two temporal factors affecting the administration of the hospital. 
He is concerned with the effects the CHAMPUS reform initiative and the PRIMUS clinics 
will have on the patient levels at the hospital. He has appointed a project officer to assess 
the impact these two variables will have on patient levels at the hospital. 

The major impact of opening two clinics in the surrounding area is that they will 
attract some of SBHACH’s clientele and reduce the MCCU earnings. But what may also 
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happen is that a ghost population (people who don’t normally go to the hospital because it 
is difficult and time consuming) may fill in the void and take up some of the capacity of the 
PRIMUS clinics and fill in the vacated capacity at SBHACH. This situation may go either 
way and is a major concern of the Hospital Commander. 

5. Managerial Position 

In order to perform his job, he depends on his staff to provide him with accu- 
rate and timely reports. He depends on data provided by the oral morning reports, emer- 
gency room report, surgical reports, and the scrubbed data from the different MIS in the 
hospital. 

Another key factor he monitors is the laboratory trend analysis. If the lab is 
finding a great deal of a certain amount of disease or sees a trend developing, the hospital 
staff must initiate action to determine if an outbreak or reoccurrence of a disease or epi- 
demic is happening. 

6. Internal and External Factors 

SBHACH has been successful in cutting back on resources spent on supplies. 
The Hospital Commander asked for a 22 percent reduction across the board and the wards 
and clinics have complied with this request. The program to drive budget cuts was primar- 
ily an educational trend. Under his guidance, the staff educated those personnel directly 
involved in keeping fiscal records at the department level. In addition, personnel receive an 
indoctrination lesson on the goal of the hospital to reduce expenditures, increase productiv- 
ity, and, as a result, earn more MCCUs. 

Another external factor that was already pointed out was the nursing shortage 
SBHACH was experiencing. The commander watches the hiring trend closely to ensure 
that an appropriate nursing staff level is maintained 
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7. Monitoring And Building Factors 



Quality of care and productivity are the key areas he monitors. He monitors the 
quality of care by the number of complaints he receives from patients about a particular 
department. Of course there will always be complaints, but if he sees a trend developing, 
he takes action to find out what is happening and whether it can be corrected 

He monitors productivity by reviewing a monthly Productivity Report that 
matches the number of MCCUs earned by a department as compared to their optimal goal 
he has established. Again, if negative trends develop, he will investigate the cause and take 
corrective action if possible. 
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APPENDIX D 



INTERVIEW OF MANAGEMENT INFORMATION SYSTEMS PERSONNEL 

A. DESCRIPTION 

This appendix summarizes several interviews conducted with personnel responsible 
for maintenance and upkeep of Management Information Systems (MIS) at Silas B. Hays 
Army Community Hospital (SBHACH). This appendix describes system details of stand- 
alone MIS providing information support at SBHACH. The information gained was used 
in determining resource usage of each MIS and to develop an understanding of what data is 
provided by each MIS. Names of the personnel assigned these billets have been omitted 
though there is nothing inappropriate in any of the interviews. 

B . SUMMARY OF INTERVIEW WITH SBHACH INFORMATION 

MANAGEMENT DIVISION PERSONNEL 

The two civilian employees working in the Information Management Division are 
tasked with performing maintenance on the Automated Quality of Care Evaluation Support 
System (AQCESS) Management Information System. 

They started the interview by pointing out that the AQCESS MIS is a relatively recent 
addition to the hospital and, having just been implemented at the first of the year (1988), 
the “bugs” are still being worked out of it. The AQCESS system runs on a DEC 1184 
computer and provides information to all clinics about patients and health-care providers. 
Each clinic is provided with a separate terminal accessing the DEC 1184 mainframe. The 
system provides quantitative information about the health-care services provided by health- 
care providers and the inpatients receiving these services at SBHACH. 
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The AQCESS system has three modules: Appointment Scheduling, Quality 

Assurance, and Patient Data. Appointment Scheduling is a decentralized appointment 
scheduling system that is slowly replacing the existing centralized appointment scheduling 
system in the hospital. They went on to explain that the appointment scheduling module 
allows the clinics to schedule their own appointments, schedule appointment referrals to 
other clinics, record appointments kept, record walk-ins, and provide print-outs to clinics 
regarding future and past schedules. This module offers a number of views of data and 
may be broken down by patient, clinic, or health-care provider over varied time periods. 
They also noted that statistical information is provided by this module which is helpful in 
determining clinic and health care provider workload levels. 

Quality Assurance is used to provide profile, monitoring, and general quality 
assurance reports. The profile reports give specific information on health-care providers. 
The information provided includes education history, personal and professional credentials, 
and credential renewal lists. Also provided are historical listings of specific patients and 
medical cases the health-care provider has treated. 

Monitoring reports are provided on both clinic and health-care providers. A general 
list of the types of health care provided, such as surgery, physical therapy, etc., is provided 
by clinic and identifies patients treated. Another important monitoring tool identifies by 
patient name if a specific health-care provider is delinquent in updating medical records. 

The last reports provided by Quality Assurance are general quality assurance reports. 
These reports summarize important data such as blood use, patient deaths, and readmission 
of patients. 

The third AQCESS module is Patient Data. This module provides a comprehensive 
record of inpatient data throughout the hospital wards. The data is a conglomeration of 
necessary information about inpatients and is used by the Patient Administration Division. 
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The AQCESS system provides both routine and ad hoc reports. Some reports are 
provided every 24-hour period; specifically, the clinic schedules for the next day are 
routinely provided to all clinics. A smaller number of reports are requested irregularly 
whenever specific information is required by resource managers. 

C. SUMMARY OF INTERVIEW WITH RESOURCE MANAGEMENT 
DIVISION PERSONNEL 

The two individuals interviewed are assigned to the Resource Management Division 
and are tasked with extracting needed information from the Uniform Chart of Accounts 
Performance Expense Reports (UCAPERS) Management Information System. 

They explained that the purpose of the UCAPERS system was to collect and report 
on two Uniform Chart of Accounts data elements. The Uniform Chart of Accounts is a 
uniform accounting procedure established in 1979. This procedure makes all military 
hospital commands report on three types of accounting data in a consistent and uniform 
manner. The three types of data reported quarterly to higher commands are expenses, 
personnel usage data, and workload statistics. The UCAPERS system reports personnel 
expense and usage data. 

The system records work performed by civilian and military health-care providers, 
stores this data, and submits the data to Health Services Command (HSC) in a form by 
which HSC can provide reimbursement of funds to SBHACH for health-care services 
provided. 

The current system of reporting to DOD the amount of health-care services provided 
by the MTF is based on a unit called a Medical Care Composite Unit (MCCU). When 
health-care providers (doctors, nurses, lab technicians,...) provide services to patients in 
the form of consults, surgery, pharmaceutical prescriptions, bed space, radiology, and 
other varied services, the MTF is credited with MCCUs depending on the type of service. 
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For example, an outpatient visit is worth 0.3 MCCUs, a live birth is valued at 10 MCCUs, 
and admission as an inpatient is worth 10 MCCUs the first day and 1 MCCU every day 
there after. All health-care services provided are input daily by data-entry clerks and 
maintained on a computer system called UCAPERS. The information is updated daily, and 
weekly a tape is run summarizing all health-care services provided by the hospital. A copy 
of the tape is sent to a DOD-run facility where the data is calculated into MCCUs. These 
MCCUs are used by DOD quarterly to provide monetary funding to SBHACH in 
reimbursement for health-care services provided at the hospital. A hard-copy report is 
forwarded to the hospital one month after the quarter has expired summarizing the MCCUs 
earned for the previous quarter. 

The system runs on Datapoint hardware connected on an Attached Resource 
Computer (ARC) network of microcomputers throughout the hospital. 

The importance of this MIS is that it is the basis for which output in the form of 
health-care services provided is related to input in the form of budgetary allocation. 

D. SUMMARY OF INTERVIEW WITH THE NON-COMMISSIONED 

OFFICER IN CHARGE OF THE PERSONNEL DIVISION 

The Non-Commissioned Officer in Charge of the Personnel Division is tasked with 
maintaining the Standard Installation Divisional Personnel System (SIDPERS) 
Management Information System. 

He explained that the SIDPERS MIS is a personnel information system keeping 
records on all assigned military personnel at the hospital. It is a personal computer system 
made by Burroughs that is deployable to remote sights. 

SIDPERS maintains records of military personnel assigned to SBHACH on a hard 
disk internal to the computer. The data fields contain standard data on each soldier as well 
as detailed information on education, training, sex, religion, next of kin, etc., that is 
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necessary to the smooth function of his organization. As information on a soldier changes, 
or as personnel are deleted or transferred, the database is updated to reflect the correct 
information. 

Every working day, the changes occurring over the past day are copied onto a floppy 
disk and hand-carried to the SIDPERS on post at Fort Ord that maintains the database post- 
wide. 

SIDPERS software allows users to view the database in different manners. It 
possesses the capabilities of a relational database that is menu driven to provide quick 
access to data that satisfies some ad hoc queries. In addition to this function, SIDPERS 
also provides word-processing capabilities. 

He explained that although the system provides excellent relational database 
capabilities, it still does not satisfy all information requirements his division is tasked with 
providing. He explained that he cannot add data fields to the database of SIDPERS. 
Without this capability, he often must use SIDPERS data with other databases and 
manually sift through records to obtain a desired view of data. Fortunately, this is the only 
limitation he could point out about the SIDPERS system. 
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APPENDIX E 



DECISION SUPPORT SYSTEM LEVELED DATA FLOW DIAGRAM 

This appendix contains the leveled data flow diagram from the context diagram (level 
0) and leveled to the functional primitive. Each bubble represents a process, with the 
lowest-level processes, functional primitives, making up the building blocks of the context 
diagram [Page- Jones 80]. Functional primitives cannot be further broken down into lower- 
level processes. Note that bubble 0 is broken down to 1.0, 2.0, and 3.0. Bubble 3.0 is 
then broken down to 3.1, 3.2, 3.3, etc., until further leveling is not possible. 




Level 0 Data Flow Diagram Context Diagram 
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Level 1 Data Flow Diagram 
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Level 2 Data Flow Diagram 
(from bubble 3.0) 
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APPENDIX F 



DECISION SUPPORT SYSTEM MINI-SPECIFICATION 
DESCRIPTION 

Contained in this appendix is a statement that governs the transformation of input data 

flow(s) into output data flow(s) for each functional primitive in the data flow diagram. 

1.0 SET UP MCCU DATABASES 

For each 24-hour period at hospital, do the following: 

1 Get NUMBER OF ADMISSIONS 

2 Get NUMBER OF PHONE CONSULTS 

3 Get NUMBER OF INPATIENTS 

4 Get NUMBER OF LIVE BIRTHS 

5 Get NUMBER OF OUTPATIENT VISITS 

6 Get NUMBER OF INPATIENT VISITS 

7 Calculate DAILY MCCUS by: 

7 . 1 (NUMBER OF ADMISSIONS x ADMISSION VALUE) + 

7.2 (NUMBER OF PHONE CONSULTS x PHONE VALUE) + 

7.3 [(NUMBER OF INPATIENTS - NUMBER OF ADMISSIONS) x 
INPATIENT VALUE] + 

7 .4 (NUMBER OF LIVE BIRTHS x BIRTH VALUE) + 

7 . 5 [(NUMBER OF INPATIENT VISITS + NUMBER OF OUTPATIENT 
VISITS) x VISIT VALUE] 

8 Put DAILY MCCUS in DAILY MCCU FILE 



If end of month then 

9 Get DAILY MCCUS 

10 Calculate MONTHLY MCCUS 

1 1 Put MONTHLY MCCUS in MONTHLY MCCU FILE 



120 



2.0 SET UP PRODUCTIVITY DATABASES 
For each clinic do the following: 

1 Get MONTHLY WORK UNITS 

2 Get AVERAGE MONTHLY HEALTH CARE PROVIDERS 

3 Calculate MONTHLY CLINIC PRODUCTIVITY by: 

3.1 MONTHLY WORK UNITS / AVERAGE MONTHLY HEALTH- 
CARE PROVIDERS 

4 Put MONTHLY CLINIC PRODUCTIVITY in CLINIC PRODUCTIVITY 
FILE 

For the hospital do the following: 

5 Calculate MONTHLY HOSPITAL PRODUCTIVITY 

6 Put MONTHLY HOSPITAL PRODUCTIVITY in HOSPITAL 
PRODUCTIVITY FILE 



3 . 1 PLOT AND CALCULATE DAILY MCCU VALUES 
If choice is display MCCU earnings to date then: 

1 Get DAILY MCCUS 

2 Calculate MCCUS earned to date 

3 Display MCCUS earned to date 

Else choice is graph most recent 30 days worth of DAILY MCCUS 

4 Get DAILY MCCUS 

5 Graph DAILY MCCUS 



3.2 PLOT AND CALCULATE MONTHLY MCCU VALUES 
If choice graph current years monthly MCCUs then 

1 Get MONTHLY MCCUS 

2 Graph MONTHLY MCCUS 

Else if choice graph previous years monthly MCCUs then 

3 Get MONTHLY MCCUS 
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4 Graph MONTHLY MCCUS 



Else if choice make predictions based on historical data then 

5 Get number of months to be predicted 

6 Get number of months to base forecast 

7 Get MONTHLY MCCUS 

8 Forecast months 

9 Display forecasted months 

9.1 If one month then 

9.2 Display 

9.3 Else more than one month then 

9.4 Graph 

Else choice is make predictions based on user predicted inputs 

10 Get number of months to be predicted 

1 1 Get number of historical months to base forecast 

12 Get MONTHLY MCCUS 

13 Get future months values 

14 Forecast months 

15 Graph forecasted months 

3 . 3 PLOT AND CALCULATE HOSPITAL PRODUCTIVITY 
If choice graph any six-month period hospital productivity then 

1 Get six-month period 

2 Get MONTHLY HOSPITAL PRODUCTIVITY 

3 Graph six-month period 

Else if choice make predictions based on historical data then 

4 Get number months to be predicted 

5 Get number of historical months to base forecast 

6 Get MONTHLY HOSPITAL PRODUCTIVITY 

7 Forecast months 

8 Graph forecasted months 
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Else choice is make predictions based on user-predicted inputs 

9 Get number of months to be predicted 

10 Get number of historical months to base forecast 

11 Get MONTHLY HOSPITAL PRODUCTIVITY 

12 Get future months values 

13 Forecast months 

14 Graph forecasted months 

3.4 PLOT AND CALCULATE CLINIC PRODUCTIVITY 
If choice graph any clinic six-month period productivity then 

1 Get clinic name 

2 Get six-month period 

3 Get MONTHLY CLINIC PRODUCTIVITY 

4 Graph six-month period 

Else if choice make predictions based on historical data then 

5 Get clinic name 

6 Get number months to be predicted 

7 Get number of historical months to base forecast 

8 Get MONTHLY CLINIC PRODUCTIVITY 

9 Forecast months 

10 Graph forecasted months 

Else choice is make predictions based on user-predicted inputs 

11 Get clinic name 

12 Get number of months to be predicted 

13 Get number of historical months to base forecast 

14 Get MONTHLY CLINIC PRODUCTIVITY 

15 Get future months values 

16 Forecast months 

17 Graph forecasted months 
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3 . 5 PERFORM MCCU ANALYSIS 

1 Present MCCU menu choice 

2 Get MCCU menu choice 

3 Present MCCU ANALYSIS 

3.6 PERFORM PRODUCnVITY ANALYSIS 

1 Present productivity menu choice 

2 Get productivity menu choice 

3 Present PRODUCTIVITY ANALYSIS 
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APPENDIX G 



DECISION SUPPORT SYSTEM DATA DICTIONARY 
DESCRIPTION 

This appendix contains definitions of data elements found in the data flow diagram 
and referenced in the mini-specification. The term or meaning of each data element may be 
found here. 

ADMISSION VALUE = 10.0 *the value earned for admitting a patient into the 
hospital* 

AVERAGE HEALTH-CARE PROVIDERS = *the average number of health-care 
providers present in a clinic for the month* 

AVERAGE MONTHLY HEALTH-CARE PROVIDERS = CLINIC NAME + 
AVERAGE HEALTH-CARE PROVIDERS 

BIRTH VALUE = 10.0 *the value earned for a live birth in the hospital* 

CLINIC PRODUCTIVITY FILE = {CLINIC NAME + MONTH + YEAR + 
PRODUCTIVITY} *file contains all clinical monthly productivity values for the 
past 24-month period* 

DAILY MCCUS = DATE + MCCUS 

DAILY MCCU FILE = {DATE + MCCUS} *file contains the current fiscal year’s 
daily MCCU earnings and has at least 30 days of data and no more than 365 
days* 

DATE = YEAR + MONTH + DAY 
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HOSPITAL PRODUCTIVITY FILE = {MONTH + YEAR + PRODUCTIVITY} *file 
contains the hospital’s past 24 months’ worth of productivity* 

INPATIENT VALUE =1.0 *the value earned for each inpatient in the hospital each 
day* 

MCCUS = *a value that equates to the amount of health services rendered by the 
hospital over a specified period of time* 

MCCU ANALYSIS = *any type of data in any format provided about either monthly or 
daily MCCUs earned in the past or projected in the future* 

MONTHLY CLINIC PRODUCTIVITY = CLINIC NAME + MONTH + YEAR + 
PRODUCTIVITY 

MONTHLY HOSPITAL PRODUCTIVITY = MONTH + YEAR + 
{PRODUCTIVITY} *file contains the past 24 months of hospital productivity* 

MONTHLY MCCUS = MONTH + YEAR + MCCUS 

MONTHLY MCCU FILE = {MONTH + MCCUS} *file contains the previous year’s 
12 months’ worth of MCCU data and the current month’s MCCU data so far* 

MONTHLY WORK UNITS = CLINIC NAME + MONTH + WORK UNITS *the 
number of work units earned by each clinic on a monthly basis* 

NUMBER OF ADMISSIONS = *admissions the past 24-hour period* 

NUMBER OF INPATIENTS = *census of the total number of inpatients past 24-hour 
period, census taken at a specific time each 24-hour period* 

NUMBER OF INPATIENT VISITS = *total number of inpatients that visited clinics in 
the past 24-hour period* 
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NUMBER OF LIVE BIRTHS = *total number of live births occurring in the past 24- 
hour period* 

NUMBER OF OUTPATIENT VISITS = *total number of outpatients that visited 
clinics in the past 24-hour period* 

NUMBER OF PHONE CONSULTS = *total number of patients that were treated over 
the phone by health-care providers in the past 24-hour period* 

PHONE VALUE = 0.3 *the value earned for a phone consult to a patient* 

PRODUCTIVITY = *for each clinic based on work units earned each month divided by 
average monthly health-care providers assigned* 

PRODUCTIVITY ANALYSIS = *any type of data in any format provided about either 
hospital monthly productivity or clinic monthly productivity* 

VISIT VALUE =1.0 *the value earned for a visit to a clinic by an inpatient or 
outpatient* 

WORK UNITS = *a value that equates to the services rendered by a clinic to inpatients 
and outpatients over a one-month period* 



127 



APPENDIX H 



DECISION SUPPORT SYSTEM STRUCTURE CHART 
DESCRIPTION 

This appendix contains the transformed data flow diagram in structure chart form. 
Data elements are shown passing between individual modules. Level 0, the context 
diagram, shows the entire structure chart on one page. It is important to show the 
morphology of the system because poorly structured systems can be identified by the 
downward flow of modules alone [Page-Jones 80]. 
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APPENDIX I 



DECISION SUPPORT SYSTEM MODULE SPECIFICATIONS 



DESCRIPTION 

This appendix contains the specification of the major modules in the structure chart 
written in pseudocode. This specification in pseudocode follows the technique of Page- 
Jones [Page-Jones 80], The module specification gives a more precise description of the 
graphical presentation found in the structure chart. This textual description gives guidance 
to the programmer in order to derive source code from system documentation [Page-Jones 
80]. 

MODULE PUT MAIN MENU 

/* Finds what user wishes to look at, MCCUs or productivity analysis*/ 

/*Checks choice for validity*/ 



Put menu choices 
Get valid choice 

If not quit then 

If request for MCCUs then call module to display MCCU menu 
Else if request for productivity then call module to display 
productivity menu 



End module 



MODULE PUT MCCU MENU 

/*Finds what user wishes to look at, thirty-day MCCU trends or monthly 
MCCUs*/ 

/*Checks choice for validity*/ 

Put menu choices 
Get valid choice 
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If not quit then 

If request for thirty-day MCCU trends then call module to 
display thirty-day MCCU menu 

Else if request for monthly MCCU data then call module to 
display monthly MCCU menu 

End module 



MODULE PUT THIRTY-DAY TREND MENU 

/♦Finds what user wishes to look at, the most recent thirty-day MCCU trend or 
MCCU earnings to date*/ 

/♦Validates choice*/ 

Put menu choice 
Get valid choice 

If not quit then 

If request for most recent thirty-day trends then call module to 
present thirty-day graph (see Figure 1-1) 

Else if request for MCCU earnings to date then call module to 
put MCCU earnings to date 

End module 



MODULE PUT THIRTY-DAY MCCU TREND GRAPH 

/♦Gets the most recent thirty days worth of daily MCCU earnings and graphs it*/ 
/♦Daily MCCUs on the vertical axis*/ 

/♦Past thirty days on the horizontal axis*/ 

Call module to get most recent thirty days worth of data 
Graph data (see Figure 1-1) 

End module 



136 



MODULE PUT MCCU EARNINGS TO DATE 

/*Gets the total MCCU earnings for the current fiscal year*/ 
/♦Totals MCCU earnings and puts MCCU earnings to date*/ 



Call module to get current year’s daily MCCUs 
Total daily MCCU earnings to date 
Put MCCU earnings to date 
End module 



MODULE PUT MONTHLY MCCU MENU 

/♦Finds what the user wishes to look at, historical or projected data*/ 

/♦Checks choice for validity*/ 

Put menu choice 
Get valid choice 

If not quit then 

If request for historic data, then call module to display graph of 
historic data 

Else if request for projected data, then call module to display 
graph of projected data 

End module 



MODULE PUT MONTHLY MCCU HISTORIC DATA 

/♦Depending on user request, graph monthly MCCUs current year’s data or graph 
previous year’s monthly MCCU data*/ 

/♦Validates choice*/ 

Put menu choice 
Get valid choice 
If not quit then 

If request for current year’s monthly MCCUs then 

Call module to get current year’s monthly MCCU data 
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Call module to graph data (see Figure 1-2) 

Else if request for previous year monthly MCCUs then 
Call module to get past 12 months of data 
Call module to graph data (see Figure 1-2) 

End module 



MODULE PUT MONTHLY MCCU PROJECTED DATA 

/♦Depending on the users choice, forecast monthly MCCU earnings based on 
historic data or user input predictions*/ 

/♦Validates choice*/ 

Put menu choice 
Get valid choice 

If not quit then 

If request for projections based on historic data then 
Get number of months to be projected from user 
Get number of months of historic data to base projection 
on from user 

Call module to get historic data 
Call module to calculate projections 
Call module to graph data (see Figure 1-2) 

Else if request for projections based on user input then 
Get number of months to be projected from user 
Get number of future months to be input by user 
Get user input of future months 
Call module to get historic data 
Call module to calculate projections 
Call module to graph data (see Figure 1-2) 

End module 
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MODULE PUT PRODUCTIVITY MENU 

/♦Gives user a choice between clinic or hospital productivity*/ 

/*validate choice*/ 

Put menu choice 
Get valid choice 
If not quit then 

If request for clinical productivity then call module to display 
clinical productivity menu choice 
Else if request for hospital productivity then call module to 
display hospital productivity menu choice 

End module 



MODULE PUT CLINICAL PRODUCTIVITY 
/*Gets choice of historic data or projected data*/ 

/♦Validates choice*/ 

Put menu choice 
Get valid choice 

If not quit then 

If request for historic clinic productivity then 
Get name of clinic from user 
Get months to be graphed from user 
Validate months requested 
Call module to get data 
Call module to graph data (see Figure 1-3) 

Else if request for projected clinic productivity then 

Call module to display clinic projected productivity trends 

End module 
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MODULE PUT CLINIC PROJECTED PRODUCTIVITY TRENDS 

/♦Gets user’s choice to forecast monthly clinic productivity based on historic data 
or user input data*/ 

/♦Validates choice*/ 

Put menu choice 
Get valid choice 
If not quit then 

If request for projections based on historic data then 
Get clinic name from user 
Get number of months to be projected from user 
Get number of months of historic data to base projection 
on from user 

Call module to get historic data 
Call module to calculate projections 
Call module to graph data (see Figure 1-3) 

Else if request for projections based on user input then 
Get clinic name from user 
Get number of months to be projected from user 
Get number of future months to be input by user 
Get user input of future months 
Call module to get historic data 
Call module to calculate projections 
Call module to graph data (see Figure 1-3) 

End module 



MODULE PUT HOSPITAL PRODUCTIVITY MENU 
/♦Gets choice of historic data or projected data*/ 
/♦Validates choice*/ 

Put menu choice 
Get valid choice 
If not quit then 
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If request for historic hospital productivity then 
Get months to be graphed from user 
Validate months requested 
Call module to get data 
Call module to graph data (see Figure 1-3) 

Else if request for projected hospital productivity then 

Call module to display projected hospital productivity 

End module 



MODULE PUT PROJECTED HOSPITAL PRODUCTIVITY 

/*Gets user’s choice to forecast monthly hospital productivity based on historic 
data or user input data*/ 

/*Validates choice*/ 

Put menu choice 
Get valid choice 

If not quit then 

If request for projections based on historic data then 
Get number of months to be projected from user 
Get number of months of historic data to base projection 
on from user 

Call module to get historic data 
Call module to calculate projections 
Call module to graph data (see Figure 1-3) 

Else if request for projections based on user input then 
Get number of months to be projected from user 
Get number of future months to be input by user 
Get user input of future months 
Call module to get historic data 
Call module to calculate projections 
Call module to graph data (see Figure 1-3) 

End module 
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Figure 1-1. Sample 30-Day MCCU Graph 
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Figure 1-2. Sample MCCU Monthly Earnings Graph 
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Figure 1-3. Sample Clinical Productivity Graph 
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